Bug#984438: questionable dependency on python3-pip

[Karsten Hilbert]

Am Wed, Mar 03, 2021 at 08:33:57PM +0100 schrieb Matthias Klose:

> >> gnumed-client depends on python3-pip. Why?
> >>
> >> The only use is in external-tools/check-prerequisites.py trying to 
> >> download the
> >> pysvg module last updated in 2012, and not ported to Python3 ...
> >
> > The helper script external-tools/check-prerequisites.py
> > certainly does not do anything obnoxious like "trying to
> > download the pysvg module". It merely tells the user how to
> > retrieve the proper version thereof.
>
> well, then it can tell to install python3-pip as well.

It now does, thanks for the suggestiong.

> > Quite apart from that the dependency can safely be demoted to
> > Recommends:, or even Suggests:, if the former is still
> > coupling too tightly.
>
> just remove it, or package the dependency properly.

Is there anything fundamentally, conceptually *wrong*
(not just not recommendable) with

Suggests: python3-pip

?

Best,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#984438: questionable dependency on python3-pip

[Karsten Hilbert]

Am Wed, Mar 03, 2021 at 07:49:29PM +0100 schrieb Matthias Klose:

> gnumed-client depends on python3-pip. Why?
>
> The only use is in external-tools/check-prerequisites.py trying to download 
> the
> pysvg module last updated in 2012, and not ported to Python3 ...

The helper script external-tools/check-prerequisites.py
certainly does not do anything obnoxious like "trying to
download the pysvg module". It merely tells the user how to
retrieve the proper version thereof.

Quite apart from that the dependency can safely be demoted to
Recommends:, or even Suggests:, if the former is still
coupling too tightly.

Thanks,
Karsten (upstream)
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#936630: gnumed-client: fixed upstream

[Karsten Hilbert]

Package: gnumed-client
Version: 1.7.8+dfsg-1
Followup-For: Bug #936630

Upstream has released 1.8.0 which supports python3 (and needs wxpython4).

Please make python3-psycopg2 a 2.7 versioned dependency as
python3-psycopg2 2.8 seems to have some problems.

Karsten

-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 
'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 5.4.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnumed-client depends on:
ii  aspell   0.60.7~20110707-6
ii  file 1:5.35-4+deb10u1
ii  gnumed-common1.7.8+dfsg-1
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  ispell   3.4.00-6+b1
ii  python   2.7.16-1
ii  python-egenix-mxdatetime 3.2.9-1
ii  python-enchant   2.0.0-1
ii  python-gnuplot   1.8-6
ii  python-hl7   0.3.4-3
ii  python-httplib2  0.11.3-2
ii  python-pip   18.1-5
ii  python-wxgtk3.0  3.0.2.0+dfsg-8
ii  python3-hl7 [python-hl7] 0.3.4-3
ii  texlive-latex-base   2018.20190227-2

Versions of packages gnumed-client recommends:
ii  aeskulap0.2.2-beta2+git20180219.8787e95-2
ii  amide   1.0.5-12+b1
ii  audiofile-tools 0.3.6-5
ii  chktex  1.7.6-2+b1
ii  dcmtk   3.6.4-2.1
ii  elinks [www-browser]0.13~20190125-3
ii  extract 1:1.8-2
ii  firefox [www-browser]   69.0-1
ii  freediams   0.9.4-2
ii  ginkgocadx  3.8.8-1
ii  gnumed-doc  1.7.8+dfsg-1
ii  gtklp   1.3.1-0.1+b1
ii  konqueror [www-browser] 4:18.12.0-1
ii  lacheck 1.26-17
ii  libimage-exiftool-perl  11.16-1
ii  libreoffice-writer  1:6.1.5-3+deb10u5
ii  ntp 1:4.2.8p12+dfsg-4
pn  pdftk   
ii  poppler-utils   0.71.0-5
ii  printer-driver-cups-pdf [cups-pdf]  3.0.1-5
ii  python-faulthandler 3.0-1
ii  python-pyqrcode 1.2.1-2
ii  python-vobject  0.9.6.1-0.1
ii  qpdf8.4.0-2
ii  texlive-latex-extra 2018.20190227-2
ii  texlive-latex-recommended   2018.20190227-2
ii  w3m [www-browser]   0.5.3-37
ii  wgerman-medical 20160103-3
ii  xdg-utils   1.1.3-1
ii  xmedcon 0.16.1+dfsg-1
ii  xsane   0.999-6+b1

Versions of packages gnumed-client suggests:
pn  autokey-qt | autokey-gtk
ii  edfbrowser  1.67+dfsg-1
ii  entangle2.0-1
pn  gimp | kolourpaint4 
ii  gnumed-server   22.8-1
ii  incron  0.5.12-1
pn  konsolekalendar 
pn  korganizer  
ii  libchipcard-tools   5.1.0beta-3
ii  nvram-wakeup1.1-4+b1
ii  pgadmin31.22.2-5
pn  python-uno  
ii  qrisk2  0.1.20150729-4
pn  shutdown-at-night   
pn  wakeonlan | etherwake | gwakeonlan  

-- no debconf information

Bug#936630: Re: Bug#936630: gnumed-client: upstream has (unreleased) py3 support

[Karsten Hilbert]

On Wed, Feb 05, 2020 at 11:17:39AM -0500, Scott Talbert wrote:

> BTW, the gnumed website seems to be having some problems.

I'm working on it.

https://www.gnumed.de/

Suitable for the watch file could be

https://www.gnumed.de/downloads/gnumed-versions.txt

or

https://www.gnumed.de/documentation/

or

https://www.gnumed.de/downloads/

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#936630: Aw: Bug#936630: gnumed-client: upstream has (unreleased) py3 support

[Karsten Hilbert]

It's done, there's even a release 1.8.rc3.

I need to convince myself to release 1.8.0 proper :-)

Karsten

> Gesendet: Donnerstag, 30. Januar 2020 um 17:25 Uhr
> Von: "Scott Talbert" 
> An: "Moritz Mühlenhoff" 
> Cc: "Karsten Hilbert" , "Debian Bug Tracking System" 
> <936...@bugs.debian.org>
> Betreff: Bug#936630: gnumed-client: upstream has (unreleased) py3 support
>
> On Tue, 17 Dec 2019, Moritz Mühlenhoff wrote:
> 
> >> Package: gnumed-client
> >> Version: 1.7.6+dfsg-1
> >> Followup-For: Bug #936630
> >>
> >> Has been ported to py3 upstream but not released yet because:
> >>
> >> Would like to be able to get bugfix-only 1.7.x py2 packages
> >> into the deb package pool until very late before bullseye
> >> so people running 1.7/py2/stable/testing can get bug fixes
> >> from the pool.
> >
> > That's unfortunately not possible:
> > The Python 2 removal operates a very complex of packages which
> > many inter dependencies, so it's not possible to keep some
> > packages around until late in the freeze cycle.
> >
> > In fact, the bug for gnumed-client got already bumped to release-critical
> > state because of reverse depencies (which triggered it's removal
> > from testing), so that's not possible.
> 
> Hi Karsten,
> 
> How is the Python 3 port of gnumed-client coming?
> 
> Scott

Bug#936630: gnumed-client: py3 available upstream

[Karsten Hilbert]

Package: gnumed-client
Version: 1.7.7+dfsg-1
Followup-For: Bug #936630

Upstream (me) has py3 support available but it needs to be
polished and released.

Karsten

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 
'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 5.2.0-2-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnumed-client depends on:
ii  aspell   0.60.7~20110707-6
ii  file 1:5.35-4
ii  gnumed-common1.7.7+dfsg-1
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  ispell   3.4.00-6+b1
ii  python   2.7.16-1
ii  python-egenix-mxdatetime 3.2.9-1
ii  python-enchant   2.0.0-1
ii  python-gnuplot   1.8-6
ii  python-hl7   0.3.4-3
ii  python-httplib2  0.11.3-2
ii  python-pip   18.1-5
ii  python-wxgtk3.0  3.0.2.0+dfsg-8
ii  python3-hl7 [python-hl7] 0.3.4-3
ii  texlive-latex-base   2018.20190227-2

Versions of packages gnumed-client recommends:
ii  aeskulap0.2.2-beta2+git20180219.8787e95-2
ii  amide   1.0.5-12+b1
ii  audiofile-tools 0.3.6-5
ii  chktex  1.7.6-2+b1
ii  dcmtk   3.6.4-2.1
ii  elinks [www-browser]0.13~20190125-3
ii  extract 1:1.8-2
ii  firefox [www-browser]   69.0-1
ii  freediams   0.9.4-2
ii  ginkgocadx  3.8.8-1
ii  gnumed-doc  1.7.7+dfsg-1
ii  gtklp   1.3.1-0.1+b1
ii  konqueror [www-browser] 4:18.12.0-1
ii  lacheck 1.26-17
ii  libimage-exiftool-perl  11.16-1
ii  libreoffice-writer  1:6.1.5-3+deb10u4
ii  ntp 1:4.2.8p12+dfsg-4
pn  pdftk   
ii  poppler-utils   0.71.0-5
ii  printer-driver-cups-pdf [cups-pdf]  3.0.1-5
ii  python-faulthandler 3.0-1
ii  python-pyqrcode 1.2.1-2
ii  python-vobject  0.9.6.1-0.1
ii  qpdf8.4.0-2
ii  texlive-latex-extra 2018.20190227-2
ii  texlive-latex-recommended   2018.20190227-2
ii  w3m [www-browser]   0.5.3-37
ii  wgerman-medical 20160103-3
ii  xdg-utils   1.1.3-1
ii  xmedcon 0.16.1+dfsg-1
ii  xsane   0.999-6+b1

Versions of packages gnumed-client suggests:
pn  autokey-qt | autokey-gtk
ii  edfbrowser  1.67+dfsg-1
ii  entangle2.0-1
pn  gimp | kolourpaint4 
ii  gnumed-server   22.5-1
ii  incron  0.5.12-1
pn  konsolekalendar 
pn  korganizer  
ii  libchipcard-tools   5.1.0beta-3
ii  nvram-wakeup1.1-4+b1
ii  pgadmin31.22.2-5
pn  python-uno  
ii  qrisk2  0.1.20150729-4
pn  shutdown-at-night   
pn  wakeonlan | etherwake | gwakeonlan  

-- no debconf information

Bug#835334: tex-common: failed on other fonts today

[Karsten Hilbert]

On Thu, Feb 02, 2017 at 10:52:24PM +0900, Norbert Preining wrote:

>>  W: APT had planned for dpkg to do more than it reported back (20 vs 24).
>> Affected packages: tex-common:i386
> 
> That is something of dpkg,

I know, just wanted to point it out.

> not related to anything in TeX Live.

I wasn't quite so sure because

a) apt blames dpkg which "blames" tex-common

b) the details given in the bug about delaying/skipping   
trigger invocations made me think it might have to do with
tex-common (or texlive-base) having to tell dpkg that some
triggers may or may not need to be run such that dpkg/apt
bean counters can adjust accordingly

Good to know it is not caused by the tex packages.

Thanks for your work !

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#818757: orthanc-postgresql: is resolved

[Karsten Hilbert]

Package: orthanc-postgresql
Followup-For: Bug #818757

Dear Maintainer,

I can report that resolving

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811141

also resolved this bug (#818757) for me !

Thanks,
Karsten

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.6.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages orthanc-postgresql depends on:
ii  libboost-system1.58.0  1.58.0+dfsg-5.1
ii  libc6  2.22-11
ii  libgcc11:6.1.1-7
ii  libjsoncpp11.7.2-1
ii  libpq5 9.5.3-1
ii  libstdc++6 6.1.1-7
ii  libuuid1   2.28-5
ii  orthanc1.1.0+dfsg-1

orthanc-postgresql recommends no packages.

Versions of packages orthanc-postgresql suggests:
ii  postgresql  9.5+175

-- Configuration Files:
/etc/orthanc/postgresql.json changed [not included]

-- no debconf information

Bug#818757: [Debian-med-packaging] Bug#818757: orthanc-postgresql: does not start

[Karsten Hilbert]

On Wed, Jun 29, 2016 at 08:07:17AM +0200, Sebastien Jodogne wrote:

> What I would need would be a full backtrace of the C++ code. This requires a
> fresh build in debug mode, with static linking, of both Orthanc 1.1.0 and
> PostgreSQL plugin 2.0. Static linking allows to become independent of a
> potential instability of your Debian setup.
> 
> After downloading the source code of each package, create a "Build"
> directory inside, and run:
> 
> # cmake .. -DSTATIC_BUILD=ON -DCMAKE_BUILD_TYPE=Debug
> # make
> 
> Obviously, make sure that your Orthanc configuration points to the newly
> built PostgreSQL plugin.
> 
> Then, please post the full gdb backtrace (command "bt") of the crash when
> you try and run [Orthanc]

Attached a full backtrace of a stock Debian Orthanc 1.1.0
with o-pg 2.0 (it is lacking symbols so might be of limited
use).

Any chance a -dbgsyms package can be provided ?

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
Skript gestartet auf Mi 29 Jun 2016 14:40:04 CEST
root@hermes:~/bin# gdb --args /usr/sbin/Orthanc --trace 
--logdir=/var/log/orthanc /etc/orthanc/
GNU gdb (Debian 7.11.1-2) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/Orthanc...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/sbin/Orthanc --trace --logdir=/var/log/orthanc 
/etc/orthanc/
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
*** stack smashing detected ***: /usr/sbin/Orthanc terminated
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x6929b)[0xb717629b]
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x37)[0xb7205eb7]
/lib/i386-linux-gnu/libc.so.6(+0xf8e78)[0xb7205e78]
/usr/share/orthanc/plugins/libOrthancPostgreSQLStorage.so(+0x11284)[0xb7fac284]
/usr/share/orthanc/plugins/libOrthancPostgreSQLStorage.so(+0xa9bf)[0xb7fa59bf]
/usr/share/orthanc/plugins/libOrthancPostgreSQLStorage.so(OrthancPluginInitialize+0xab)[0xb7fabd7b]
/usr/sbin/Orthanc(+0xd8007)[0x800d8007]
/usr/sbin/Orthanc(+0xd8b70)[0x800d8b70]
/usr/sbin/Orthanc(+0xd8161)[0x800d8161]
/usr/sbin/Orthanc(main+0x4cd)[0x8002400d]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf7)[0xb7125517]
/usr/sbin/Orthanc(+0x2b568)[0x8002b568]
=== Memory map: 
8000-802ad000 r-xp  08:01 6288261/usr/sbin/Orthanc
802ad000-802b1000 r--p 002ac000 08:01 6288261/usr/sbin/Orthanc
802b1000-802b2000 rw-p 002b 08:01 6288261/usr/sbin/Orthanc
802b2000-804e7000 rw-p  00:00 0  [heap]
b4978000-b49a8000 r-xp  08:01 6898193
/usr/lib/i386-linux-gnu/libpq.so.5.8
b49a8000-b49aa000 r--p 0002f000 08:01 6898193
/usr/lib/i386-linux-gnu/libpq.so.5.8
b49aa000-b49ab000 rw-p 00031000 08:01 6898193
/usr/lib/i386-linux-gnu/libpq.so.5.8
b49ab000-b49df000 r-xp  08:01 6899772
/usr/lib/i386-linux-gnu/libjsoncpp.so.0.10.5
b49df000-b49e r--p 00033000 08:01 6899772
/usr/lib/i386-linux-gnu/libjsoncpp.so.0.10.5
b49e-b49e1000 rw-p 00034000 08:01 6899772
/usr/lib/i386-linux-gnu/libjsoncpp.so.0.10.5
b4a34000-b4a3d000 rw-p  00:00 0 
b4a3d000-b4a44000 r-xp  08:01 6899295
/usr/lib/i386-linux-gnu/libffi.so.6.0.4
b4a44000-b4a45000 r--p 6000 08:01 6899295
/usr/lib/i386-linux-gnu/libffi.so.6.0.4
b4a45000-b4a46000 rw-p 7000 08:01 6899295
/usr/lib/i386-linux-gnu/libffi.so.6.0.4
b4a46000-b4a5a000 r-xp  08:01 8151438
/lib/i386-linux-gnu/libgpg-error.so.0.19.0
b4a5a000-b4a5b000 r--p 00013000 08:01 8151438
/lib/i386-linux-gnu/libgpg-error.so.0.19.0
b4a5b000-b4a5c000 rw-p 00014000 08:01 8151438
/lib/i386-linux-gnu/libgpg-error.so.0.19.0
b4a5c000-b4a6e000 r-xp  08:01 6899143
/usr/lib/i386-linux-gnu/libtasn1.so.6.5.2
b4a6e000-b4a6f000 ---p 00012000 08:01 6899143
/usr/lib/i386-linux-gnu/libtasn1.so.6.5.2
b4a6f000-b4a7 r--p 00012000 08:01 6899143
/usr/lib/i386-linux-gnu/libtasn1.so.6.5.2
b4a7-b4a71000 rw-p 00013000 08:01 6899143
/usr/lib/i386-linux-gnu/libtasn1.so.6.5.2
b4a71000-b4a72000 rw-p  00:00 0 
b4a72000-b4ace000 r-xp  08:01 6898110
/usr/lib/i386-linux-gnu/libp11-kit.so.0.1.0
b4ace000-b4ad3000 r--p 0005b000 08:01 6898110
/usr/lib/i386-linux-gnu/libp11-kit.so.0.1.0
b4ad3000-b4ad4000 rw-p 

Bug#818757: [Debian-med-packaging] Bug#818757: orthanc-postgresql: does not start

[Karsten Hilbert]

On Mon, Jun 27, 2016 at 11:03:36AM +0200, Sébastien Jodogne wrote:

> > - I would not have guessed that adding --upgrade might have made
> >   a difference to a failure that tells me "stack smashing detected"
> >   at the console :-)
> 
> Just to be sure: Is your issue an immediate crash with "stack smashing 
> detected", or is your issue a failure while executing the "--upgrade"?

Both are (were) issues for me.

I have attempted to solve the upgrade issue by
dropping/re-creating the database in PostgreSQL
because the database did not hold production data.

However, Orthanc-on-PG does not start anymore because the PG
plugin now crashes with "stack smashing detected" so I cannot
verify whether it would properly start with the new empty
database ...

> In the former case, couldn't it be possible that the
> version of some shared library does not match its version of
> the headers, maybe because of an unstable Debian?

That is surely possible. That is why I offered to provide
more information if told how to do so.


> > Would you mind adding a line to the log indicating that
> > --upgrade might be needed when Orthanc detects that situation
> > at startup ?
> 
> This is already the case; Here is a sample log of Orthanc 1.0.0 asking an 
> upgrade with the PostgreSQL plugins 2.0 (notice the line starting with "E"):

I figured that out. It didn't have that line in the log when
I first attempted the upgrade.

Thanks,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#818757: orthanc-postgresql: does not start

[Karsten Hilbert]

On Sun, Mar 27, 2016 at 01:13:03PM +0200, Karsten Hilbert wrote:

> Is there anything else I can provide to get this bug looked at ?

Even if I risk to be a pain in the behind - since this
package is of such importance to responsible Medical Care
I allow myself to re-inquire about the state of this bug.

Thanks for looking,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#818757: [Debian-med-packaging] Bug#818757: orthanc-postgresql: does not start

[Karsten Hilbert]

Hi Sébastien,

welcome back.

> I am back from vacations. I will look at the upgrade problem as soon as 
> possible.

I don't think it is an upgrade problem.

> As a quick hack to unblock you,

Fortunately, this is on a testing machine. No production data
at risk - that instance still runs on sqlite.

Just for good measure I have dropped the DB, recreated a new
empty one and restarted with the same crash.

> This upgrade problem should not occur again in the future,
> as I think that the database schema has reached its final
> state since Orthanc 1.0.0.

:-)

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#818757: Bug#818757: orthanc-postgresql: does not start

[Karsten Hilbert]

Is there anything else I can provide to get this bug looked at ?

Thanks,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#818757: Bug#818757: orthanc-postgresql: does not start

[Karsten Hilbert]

On Sun, Mar 20, 2016 at 06:55:50PM +0100, Andreas Tille wrote:

> > > Have you added the "--upgrade" option so that Orthanc would automatically 
> > > upgrade the database schema?
> 
> I wonder whether this should be done in a postinst script.

Only if the database upgrade does not make a difference with
respect to client connectivity. Hence - for Orthanc this may
work (DICOM and REST access stay the same) while for GNUmed
this would not work AT ALL.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#818757: [Debian-med-packaging] Bug#818757: orthanc-postgresql: does not start

[Karsten Hilbert]

On Sun, Mar 20, 2016 at 05:55:10PM +0100, Sébastien Jodogne wrote:

> > 4) the existing orthanc_db is 0.8 and the jump is to Orthanc 1.0 (orthanc-pg
> > 2.0)
> 
> Have you added the "--upgrade" option so that Orthanc would automatically 
> upgrade the database schema?

I now did run Orthanc with --upgrade and it crashes with the
same error.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#818757: [Debian-med-packaging] Bug#818757: orthanc-postgresql: does not start

[Karsten Hilbert]

On Sun, Mar 20, 2016 at 05:55:10PM +0100, Sébastien Jodogne wrote:

> > 4) the existing orthanc_db is 0.8 and the jump is to Orthanc 1.0 (orthanc-pg
> > 2.0)
> 
> Have you added the "--upgrade" option so that Orthanc would automatically 
> upgrade the database schema?

I have not because

- it's not really me calling /usr/bin/Orthanc but /etc/init.d/orthanc
  (I only copied that call manually in order to get more information)

- I didn't know that option existed

- I would not have guessed that adding --upgrade might have made
  a difference to a failure that tells me "stack smashing detected"
  at the console :-)

- I knew from past experience that Orthanc auto-upgraded the schema
  (but that was on SQLite and from major to major w/o a version skip)

However, I will now add this option and report back.

Would you mind adding a line to the log indicating that
--upgrade might be needed when Orthanc detects that situation
at startup ?

Also, would Debian benefit from an

/usr/sbin/orthanc_upgrade

script which calls /usr/sbin/Orthanc --upgrade plus other options ?

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#818757: orthanc-postgresql: does not start

[Karsten Hilbert]

Package: orthanc-postgresql
Version: 2.0-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Orthanc does not start when the backend is set to PostgreSQL.

1) I can successfully

su - orthanc
psql -d orthanc_db

2) Orthanc will start if set to using the sqlite backend

3) it worked before dist-upgrading jessie to stretch

4) the existing orthanc_db is 0.8 and the jump is to Orthanc 1.0 (orthanc-pg 
2.0)

Logs attached.

Karsten

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages orthanc-postgresql depends on:
ii  libboost-system1.58.0  1.58.0+dfsg-5+b1
ii  libc6  2.22-3
ii  libgcc11:5.3.1-11
ii  libjsoncpp0v5  0.10.5-1
ii  libpq5 9.5.1-1
ii  libstdc++6 5.3.1-11
ii  libuuid1   2.27.1-6
ii  orthanc1.0.0+dfsg-1+b1

orthanc-postgresql recommends no packages.

Versions of packages orthanc-postgresql suggests:
ii  postgresql  9.5+172

-- Configuration Files:
/etc/orthanc/postgresql.json changed:
{
/**
 * Configuration to use PostgreSQL instead of the default SQLite
 * back-end of Orthanc. You will have to install the
 * "orthanc-postgresql" package to take advantage of this feature.
 * Have a look at "/usr/share/doc/orthanc-postgresql/README.Debian"
 * for a tutorial.
 **/
"PostgreSQL" : {
// Enable the use of PostgreSQL to store the Orthanc index?
"EnableIndex" : true,
// Enable the use of PostgreSQL to store the DICOM files?
"EnableStorage" : true,
// Option 1: Specify explicit authentication parameters
//"Host" : "localhost",
//"Port" : 5432,
//"Database" : "orthanc_db",
//"Username" : "orthanc_user",
//"Password" : "my_password",
// Option 2: Authenticate using PostgreSQL connection URI
// "ConnectionUri" : 
"postgresql://orthanc_user:my_password@localhost:5432/orthanc_db",
"ConnectionUri" : "postgresql:///orthanc_db?user=orthanc",
// Optional: Disable the locking of the PostgreSQL database
"Lock" : false
}
}


-- no debconf information
Skript gestartet auf So 20 Mär 2016 14:08:50 CET
root@hermes:~# /usr/sbin/Orthanc --trace --logdir=/var/log/orthanc /etc/orthanc/
*** stack smashing detected ***: /usr/sbin/Orthanc terminated
=== Backtrace: =
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x692ab)[0xb691a2ab]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x37)[0xb69a9fe7]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xf8fa8)[0xb69a9fa8]
/usr/share/orthanc/plugins/libOrthancPostgreSQLStorage.so(+0x11284)[0xb41fa284]
/usr/share/orthanc/plugins/libOrthancPostgreSQLStorage.so(+0xa9bf)[0xb41f39bf]
/usr/share/orthanc/plugins/libOrthancPostgreSQLStorage.so(OrthancPluginInitialize+0xab)[0xb41f9d7b]
/usr/sbin/Orthanc[0x8107c42]
/usr/sbin/Orthanc[0x8108aa3]
/usr/sbin/Orthanc[0x8107da9]
/usr/sbin/Orthanc[0x8068e48]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xf7)[0xb68c9527]
/usr/sbin/Orthanc[0x806f2fa]
=== Memory map: 
08048000-082c9000 r-xp  08:01 12230893   /usr/sbin/Orthanc
082c9000-082ca000 r--p 0028 08:01 12230893   /usr/sbin/Orthanc
082ca000-082cb000 rw-p 00281000 08:01 12230893   /usr/sbin/Orthanc
082cb000-082cd000 rw-p  00:00 0 
0870b000-0894 rw-p  00:00 0  [heap]
b4147000-b4177000 r-xp  08:01 6898379
/usr/lib/i386-linux-gnu/libpq.so.5.8
b4177000-b4179000 r--p 0002f000 08:01 6898379
/usr/lib/i386-linux-gnu/libpq.so.5.8
b4179000-b417a000 rw-p 00031000 08:01 6898379
/usr/lib/i386-linux-gnu/libpq.so.5.8
b417a000-b41ae000 r-xp  08:01 6899772
/usr/lib/i386-linux-gnu/libjsoncpp.so.0.10.5
b41ae000-b41af000 r--p 00033000 08:01 6899772
/usr/lib/i386-linux-gnu/libjsoncpp.so.0.10.5
b41af000-b41b rw-p 00034000 08:01 6899772
/usr/lib/i386-linux-gnu/libjsoncpp.so.0.10.5
b41e9000-b420 r-xp  08:01 6283388
/usr/lib/libOrthancPostgreSQLStorage.so.2.0
b420-b4201000 r--p 00016000 08:01 6283388
/usr/lib/libOrthancPostgreSQLStorage.so.2.0
b4201000-b4202000 rw-p 00017000 08:01 6283388
/usr/lib/libOrthancPostgreSQLStorage.so.2.0
b4202000-b420b000 rw-p  00:00 0 
b420b000-b4212000 r-xp  08:01 6899295
/usr/lib/i386-linux-gnu/libffi.so.6.0.4
b4212000-b4213000 r--p 6000 08:01 6899295
/usr/lib/i386-linux-gnu/libffi.so.6.0.4
b4213000-b4214000 rw-p 7000 08:01 6899295
/usr/lib/i386-linux-gnu/libffi.so.6.0.4
b4214000-b4228000 r-xp  08:01 8151062
/lib/i386-linux-gnu/libgpg-error.so.0.17.0
b4228000-b4229000 r--p 00013000 

Bug#787877: clinica: contingency options

[Karsten Hilbert]

Package: clinica
Version: 0.3.0-1
Followup-For: Bug #787877

For what it is worth: GNUmed (gnumed-client) offers code to import a
Clinica database.

Karsten

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (50, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.0.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages clinica depends on:
ii  clinica-common 0.3.0-1
ii  gir1.2-clinica-0.3 0.3.0-1
ii  libatk1.0-02.16.0-2
ii  libc6  2.19-19
ii  libcairo-gobject2  1.14.2-2
ii  libcairo2  1.14.2-2
ii  libclinica00.3.0-1
ii  libgdk-pixbuf2.0-0 2.31.4-2
ii  libgee20.6.8-2
ii  libgirepository-1.0-1  1.44.0-1+b2
ii  libglib2.0-0   2.44.1-1.1
ii  libgtk-3-0 3.16.5-1
ii  libjansson42.7-3
ii  libpango-1.0-0 1.36.8-3
ii  libpangocairo-1.0-01.36.8-3
ii  libpeas-1.0-0  1.12.1-2
ii  librsvg2-2 2.40.9-2
ii  libsoup2.4-1   2.50.0-2
ii  libsqlite3-0   3.8.10.2-1

clinica recommends no packages.

clinica suggests no packages.

-- no debconf information


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

Bug#766956: postgresql: 9.4 not released upstream

[Karsten Hilbert]

On Mon, Oct 27, 2014 at 11:48:37AM +0100, Christoph Berg wrote:

  If so that'd solve the apparent problem. It won't prevent
  the following scenario though:
  
  - Jessie is released with PG 9.4.betaX
  - PG releases 9.4.betaX+1 which requires a dump/restore
cycle due to a catalog bump (PG doesn't guarantuee
catalog stability across betas as much as across
released minors)
  - now people running PG on Debian STABLE need to
dump/restore their clusters
 
 This was the last 9.4 catversion bump.

Just FYI:

Andrew Dunstan pushed:

- Correct volatility markings of a few json functions.  json_agg and
  json_object_agg and their associated transition functions should
  have been marked as stable rather than immutable, as they call IO
  functions indirectly. Changing this probably isn't going to make
  much difference, as you can't use an aggregate function in an index
  expression, but we should be correct nevertheless.  json_object, on
  the other hand, should be marked immutable rather than stable, as it
  does not call IO functions.  As discussed on -hackers, this change
  is being made without bumping the catalog version, as we don't want
  to do that at this stage of the cycle, and  the changes are very
  unlikely to affect anyone.
  
http://git.postgresql.org/pg/commitdiff/af2b8fd057213f4b1918b9581c63e0b00427573c

So it's not like it can't happen.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


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

Bug#766956: postgresql: 9.4 not released upstream

[Karsten Hilbert]

Package: postgresql
Version: 9.4+163
Severity: serious
Tags: upstream
Justification: 5.a)

Hi,

since it is now less than 10 days from Nov 5th and upstream hasn't
released PostgreSQL 9.4 just yet

http://www.postgresql.org/docs/9.4/static/release-9-4.html

I wonder what the rationale is for this metapackage to depend on 9.4 ?

A catalog bump *did* happen between beta2 and beta3, for example.

Karsten

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 
'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.16-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages postgresql depends on:
ii  postgresql-9.4  9.4~beta3-3

postgresql recommends no packages.

Versions of packages postgresql suggests:
pn  postgresql-doc  none

-- no debconf information


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

Bug#766956: postgresql: 9.4 not released upstream

[Karsten Hilbert]

On Mon, Oct 27, 2014 at 11:48:37AM +0100, Christoph Berg wrote:

  If so that'd solve the apparent problem. It won't prevent
  the following scenario though:
  
  - Jessie is released with PG 9.4.betaX
  - PG releases 9.4.betaX+1 which requires a dump/restore
cycle due to a catalog bump (PG doesn't guarantuee
catalog stability across betas as much as across
released minors)
  - now people running PG on Debian STABLE need to
dump/restore their clusters
 
 This was the last 9.4 catversion bump.

Fingers crossed.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


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

Bug#685351: Bug#687702: gnumed-client: t-p-o candidate on 1.1 maintenance branch available

[Karsten Hilbert]

On Thu, Oct 11, 2012 at 10:05:48PM +0200, Andreas Tille wrote:

  Hi Andreas,
  
  is there anything I can do to help make this happen ?
  
  687702: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687702
 
 I'm *way* *more* worried about #685351

I thought #685351 got fixed ?!?

 which could lead to remove gnumed
 completely and it is on my todo list for the weekend.

Ah, I see. I think we did identify a solution but it had to
wait for you to return to get implemented.

  Lets concentrate onto this first.

Sure.

  I guess you haven't gotten through with your backlog of
  email just yet.
 
 For #687702 you might like to ask debian-rele...@lists.debian.org about
 their opinion but I doubt that they will consider an inclusion into
 stable release if there are no bugs fixed which are considered RC.

Of course and I agree with that.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


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

Bug#685351: Commited source to svn [Was: Bug#685351: src:gnumed-client: Missing source code for *.js files]

[Karsten Hilbert]

On Thu, Sep 20, 2012 at 06:54:50AM +0200, Andreas Tille wrote:

 just to keep a record:  I commited the JS sources in question to gnumed
 packaging SVN.

Thanks so much for taking care of this issue.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


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

Bug#685351: Commited source to svn [Was: Bug#685351: src:gnumed-client: Missing source code for *.js files]

[Karsten Hilbert]

On Thu, Sep 20, 2012 at 06:54:50AM +0200, Andreas Tille wrote:

 In case no other team member will upload or somebody will
 NMU I'll upload not before 5.10.2012 because I'm on vac.

Is there any risk of 1.1.19 not getting considered for a
freeze exception simply because of that (IOW, the 5th of Oct
simply being too late) ?

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


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

Bug#608190: [Debian-med-packaging] Bug#608190: /etc/gnumed/gnumed-client.conf has wrong database name

[Karsten Hilbert]

On Tue, Dec 28, 2010 at 11:51:46PM +0900, Charles Plessy wrote:

  Just to clear this up: this bug applies to GNUmed 0.7.10-1
  from Squeeze and NOT to 0.8.5 from sid.

 I hope the above control commands will correctly summarise the situation in 
 the
 BTS.

Looks right to me.

@Release team: Note that I am NOT asking for 0.8 to be moved
from Unstable to Testing. I am rather wondering whether a
0.7.10-2 should be created and uploaded to t-p-u. If so that
would need either Andreas or someone else from the Debian
Med team to do an upload.

Thanks,
Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



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

Bug#605159: gnumed-client: Use of PYTHONPATH env var in an insecure way

[Karsten Hilbert]

On Tue, Nov 30, 2010 at 05:25:00PM +0100, Andreas (Debian) wrote:

 thanks to the support of upstream there is a new release which fixes the
 issue.  However, the issue does not even really exist in *effective*
 upstream code - it is just contained in a *comment* which is simlpy
 activated in a patch in the Debian packaging.  So I wonder what might
 be the best strategy to handle this.
 
   1. Use upstream bugfix version which provides the proper PYTHONPATH
  setting in the comment which will be activated later plus a
  7 line patch in some unrelated code which is unlikely to break
  something else.

Just for the record: those 7 lines fix another bug which
resulted in a crash (Python exception) when doctors tried to
document hospital admissions of their patients. This bug fix
has long been in production outside of Debian (and inside
the version 0.8.4 from Debian/Unstable) so there's no
known technical risk associated with it:

 +FIX: exception on trying to create hospital stay w/o episode [thanks devm]

...

 + if self._PRW_episode.GetValue().strip() == u'':
 + self._PRW_episode.display_as_valid(False)
 + wxps.Publisher().sendMessage (
 + topic = 'statustext',
 + data = {'msg': _('Must select an episode or 
 enter a name for a new one. Cannot save hospital stay.'), 'beep': True}
 + )
 + return False

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



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

Bug#605159: gnumed-client: Use of PYTHONPATH env var in an insecure way

[Karsten Hilbert]

Fixed upstream in 0.7.10 and 0.8.5.

Please consider 0.7.10 for migration to squeeze.

Changelog:

0.7.10

FIX: exception on trying to create hospital stay w/o episode [thanks 
devm]
FIX: properly set PYTHONPATH [thanks JB and Debian Squeeze (#605159)]

Download:

http://www.gnumed.de/downloads/client/0.7/

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



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

Bug#559349: kdebase-workspace-bin: not installable due to missing dependency libxklavier15, renders KDE unusable

[Karsten Hilbert]

Package: kdebase-workspace-bin
Severity: grave
Justification: renders package unusable

After an

apt-get update
apt-get dist-upgrade

today KDE will not start anymore because this package is not installable
due to the libxklavier15 dependancy.

Due to this the apt-get dist-upgrade should not have happened so in
reality there is very likely a *dependancy on kdebase-workspace-bin*
missing somehwere else.

Karsten

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.31-trunk-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages kdebase-workspace-bin depends on:
ii  kaboom1.1.2  The Debian KDE settings migration 
ii  kdebase-runtime   4:4.3.2-1  runtime components from the offici
ii  kdebase-workspace-data4:4.3.2-2  shared data files for the KDE 4 ba
ii  kdebase-workspace-kgreet- 4:4.3.2-2  KDE greet libraries for authentica
ii  kdelibs5  4:4.3.2-2  core libraries for all KDE 4 appli
ii  libc6 2.10.2-2   GNU C Library: Shared libraries
ii  libdbus-1-3   1.2.16-2   simple interprocess messaging syst
ii  libfontconfig12.6.0-4generic font configuration library
ii  libfreetype6  2.3.11-1   FreeType 2 font engine, shared lib
ii  libgcc1   1:4.4.2-3  GCC support library
ii  libgl1-mesa-glx [libgl1]  7.6-1  A free implementation of the OpenG
ii  libglib2.0-0  2.22.2-2   The GLib library of C routines
ii  libice6   2:1.0.5-1  X11 Inter-Client Exchange library
ii  libkephal44:4.3.2-2  API for easier handling of multihe
ii  libkfontinst4 4:4.3.2-2  Libraries for font installation in
ii  libknotificationitem-1-1  4:4.3.2-1  library for new way of handling sy
ii  libkscreensaver5  4:4.3.2-2  Library of the KDE Screensaver sys
ii  libkworkspace44:4.3.2-2  Library for the kdebase workspace
ii  libnepomukquery4  4:4.3.2-2  Library for the nepomuk search
ii  libnepomukqueryclient44:4.3.2-2  Library for the nepomuk client sea
ii  libpam0g  1.1.0-4Pluggable Authentication Modules l
ii  libphonon44:4.5.3-4  Qt 4 Phonon module
ii  libplasma34:4.3.2-2  library for the KDE 4 Plasma deskt
ii  libpng12-01.2.40-1   PNG library - runtime
ii  libpolkit-dbus2   0.9-4  library for accessing PolicyKit vi
ii  libpolkit-grant2  0.9-4  library for obtaining privileges v
ii  libpolkit-qt0 0.9.2-2PolicyKit-qt library
ii  libpolkit20.9-4  library for accessing PolicyKit
ii  libprocessui4 4:4.3.2-2  Library for ksysguard process user
ii  libqimageblitz4   1:0.0.4-4  QImageBlitz image effects library
ii  libqt4-dbus   4:4.5.3-4  Qt 4 D-Bus module
ii  libqt4-qt3support 4:4.5.3-4  Qt 3 compatibility library for Qt 
ii  libqt4-script 4:4.5.3-4  Qt 4 script module
ii  libqt4-xml4:4.5.3-4  Qt 4 XML module
ii  libqtcore44:4.5.3-4  Qt 4 core module
ii  libqtgui4 4:4.5.3-4  Qt 4 GUI module
ii  libsm62:1.1.1-1  X11 Session Management library
ii  libsolidcontrol4  4:4.3.2-2  Library for solid based network ma
ii  libsolidcontrolifaces44:4.3.2-2  Library for solid based network in
ii  libsoprano4   2.3.1+dfsg.1-1 libraries for the Soprano RDF fram
ii  libstdc++64.4.2-3The GNU Standard C++ Library v3
ii  libstreamanalyzer00.7.0-1+b2 streamanalyzer library for Strigi 
ii  libusb-0.1-4  2:0.1.12-13userspace USB programming library
ii  libx11-6  2:1.2.2-1  X11 client-side library
ii  libxau6   1:1.0.5-1  X11 authorisation library
ii  libxcursor1   1:1.1.9-1  X cursor management library
ii  libxext6  2:1.0.4-1  X11 miscellaneous extension librar
ii  libxfixes31:4.0.3-2  X11 miscellaneous 'fixes' extensio
ii  libxi62:1.2.1-2  X11 Input extension library
ii  libxinerama1  2:1.0.3-2  X11 Xinerama extension library
ii  libxklavier12 3.9-1  X Keyboard Extension high-level AP
ii  libxrandr22:1.3.0-2  X11 RandR extension library
ii  libxrender1   1:0.9.4-2  X Rendering Extension client libra
ii  libxss1   1:1.1.3-1  X11 Screen Saver extension library
ii  libxtst6  2:1.0.3-1  X11 Testing -- Resource extension 
ii  libxxf86misc1  

Bug#557495: [trei...@free.fr: Bug#557495: libtowitoko-dev and libctapimkt0-dev: error when trying to install together]

[Karsten Hilbert]

On Mon, Nov 23, 2009 at 04:01:18PM +0100, Andreas Tille wrote:

 I realised that there are all in all three packages in Debian which
 are acceccing a CT-API and providing a file ctapi.h:
 
 $ apt-file search ctapi.h
 libctapimkt0-dev: /usr/include/ctapi.h
 libopenct1-dev: /usr/include/openct/ctapi.h
 libtowitoko-dev: /usr/include/ctapi.h

...

 The other solution would be [...] to simply conclict with
 libtowitoko-dev - but I have no idea whether this is reasonable

No way :-)I want both libtowitoko and libctapimkt at the
same time. Both provide access to particular chipcard
readers by providing the standard CT-API for other code to
rely on.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



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

Bug#540254: alsa-utils: /etc/init.d/alsa-util Ctrl-D's the boot process

[Karsten Hilbert]

Package: alsa-utils
Version: 1.0.20-2
Severity: serious
Justification: stops machine boot

This happens during boot and triggers a stop asking for the root
password for maintenance or Ctlr-D to continue rebooting anyway:

merkur:~# /etc/init.d/alsa-utils restart
Shutting down ALSA...done.
Setting up ALSA...warning: 'alsactl restore' failed with error message 'Unknown 
hardware: SI7018 SigmaTel STAC9700,83,84,Silicon Laboratory Si3036,8 rev 1 
AC97a:83847600 AC97m:53494c21 0x1043 0x1453
Hardware is initialized using a guess method
/usr/share/alsa/init/default:51: control element not found
/usr/share/alsa/init/default:52: missing closing brace for format
/usr/share/alsa/init/default:52: error parsing CTL attribute
/usr/share/alsa/init/default:52: invalid rule'...done.

This is the relevant section in /usr/share/alsa/init/default:

CTL{reset}=mixer
CTL{name}=Headphone Playback 
Volume,PROGRAM==__ctl_search,GOTO=headphone0_end
# if master volume control is present, turn headphone volume to max
ENV{has_pmaster_vol}==true,CTL{values}=0dB,RESULT==0,GOTO=headphone0_end
ENV{has_pmaster_vol}==true,CTL{values)=100%,GOTO=headphone0_end
CTL{values}=$env{pvolume},RESULT!=0,CTL{values}=$env{ppercent}
LABEL=headphone0_end
CTL{name}=Headphone Playback Switch,PROGRAM==__ctl_search, \
  CTL{values}=on


Line 51 is the first one starting with ENV.

Karsten


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages alsa-utils depends on:
ii  dialog1.1-20080819-1 Displays user-friendly dialog boxe
ii  libasound21.0.20-2   shared library for ALSA applicatio
ii  libc6 2.9-12 GNU C Library: Shared libraries
ii  libncurses5   5.7+20090523-1 shared libraries for terminal hand
ii  linux-sound-base  1.0.20+dfsg-1  base package for ALSA and OSS soun
ii  lsb-base  3.2-23 Linux Standard Base 3.2 init scrip
ii  module-init-tools 3.9-2  tools for managing Linux kernel mo
ii  whiptail  0.52.10-4  Displays user-friendly dialog boxe

Versions of packages alsa-utils recommends:
ii  alsa-base  1.0.20+dfsg-1 ALSA driver configuration files
ii  pciutils   1:3.1.3-1 Linux PCI Utilities

alsa-utils suggests no packages.

-- no debconf information



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

Bug#497382: closed by Micha Lenk [EMAIL PROTECTED] (Re: Bug#497382: [Libchipcard] #8: kvkcard segfaults reading eGK)

[Karsten Hilbert]

On Sat, Oct 18, 2008 at 04:57:04PM +, Debian Bug Tracking System wrote:

 #497382: libchipcard-tools: kvkcard segfaults when reading eGK

This seems fixed now.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



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

Bug#494374: linux-image-2.6.26-1-686: fixed for me

[Karsten Hilbert]

Package: linux-image-2.6.26-1-686
Followup-For: Bug #494374

This bug is fixed on my ASUS L2000D, too. Great.

Karsten

-- Package-specific info:
** Version:
Linux version 2.6.26-1-686 (Debian 2.6.26-8) ([EMAIL PROTECTED]) (gcc version 
4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 SMP Thu Oct 9 15:18:09 UTC 
2008

** Command line:
root=/dev/hda1 ro vga=791 lapic resume=/dev/hda5 

** Not tainted

** Kernel log:
[9.812583] hdc: UDMA/33 mode selected
[9.861947] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[   10.392005] ide1 at 0x170-0x177,0x376 on irq 15
[   10.564264] hda: max request size: 512KiB
[   10.627590] hda: 156301488 sectors (80026 MB) w/8192KiB Cache, 
CHS=16383/255/63
[   10.680003] hda: cache flushes supported
[   10.724161]  hda: hda1 hda2  hda5 
[   10.807649] hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache
[   10.856228] Uniform CD-ROM driver Revision: 3.20
[   11.338322] PM: Starting manual resume from disk
[   11.571725] kjournald starting.  Commit interval 5 seconds
[   11.621145] EXT3-fs: mounted filesystem with ordered data mode.
[   14.039207] udevd version 125 started
[   16.323966] Linux agpgart interface v0.103
[   17.085216] agpgart: Detected SiS chipset - id:1840
[   17.144003] agpgart: AGP aperture is 64M @ 0xec00
[   17.293404] input: Power Button (FF) as /class/input/input2
[   18.016350] ACPI: Power Button (FF) [PWRF]
[   18.780550] input: Power Button (CM) as /class/input/input3
[   19.347220] ACPI: Power Button (CM) [PWRB]
[   19.539006] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[   19.789627] Yenta: CardBus bridge found at :00:0a.0 [1043:1594]
[   19.973875] input: PC Speaker as /class/input/input4
[   20.079072] input: Sleep Button (CM) as /class/input/input5
[   20.511380] ACPI: Unable to turn cooling device [db422748] 'on'
[   20.684701] Yenta: ISA IRQ mask 0x0498, PCI irq 11
[   20.735448] Socket status: 3006
[   20.828787] ACPI: Sleep Button (CM) [SLPB]
[   20.946897] Asus Laptop ACPI Extras version 0.30
[   21.003432]   L2D model detected, supported
[   21.078390] Yenta: CardBus bridge found at :00:0a.1 [1043:1594]
[   21.389124] input: Lid Switch as /class/input/input6
[   21.451792] Synaptics Touchpad, model: 1, fw: 4.6, id: 0x925ea1, caps: 
0x80471b/0x0
[   21.502264] Yenta: ISA IRQ mask 0x0018, PCI irq 5
[   21.551088] Socket status: 3006
[   21.604005] ACPI: Lid Switch [LID]
[   21.652765] ACPI: AC Adapter [AC] (on-line)
[   21.766391] ACPI: Battery Slot [BAT0] (battery present)
[   21.852789] input: SynPS/2 Synaptics TouchPad as /class/input/input7
[   21.939174] parport_pc 00:0a: reported by Plug and Play ACPI
[   21.988869] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP]
[   22.093084] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 3
[   22.143178] PCI: setting IRQ 3 as level-triggered
[   22.143183] ACPI: PCI Interrupt :00:01.4[B] - Link [LNKB] - GSI 3 
(level, low) - IRQ 3
[   22.284601] Error: Driver 'pcspkr' is already registered, aborting...
[   22.715376] ACPI: PCI Interrupt :00:01.6[C] - Link [LNKC] - GSI 5 
(level, low) - IRQ 5
[   22.783906] gameport: Trident 4DWave is pci:00:01.4/gameport0, speed 
2130kHz
[   22.836965] codec_semaphore: semaphore is not ready [0x1][0x1300]
[   22.889524] codec_semaphore: semaphore is not ready [0x1][0x1300]
[   22.940706] codec_semaphore: semaphore is not ready [0x1][0x1300]
[   22.991149] codec_semaphore: semaphore is not ready [0x1][0x300]
[   23.040762] codec_semaphore: semaphore is not ready [0x1][0x300]
[   23.091536] codec_semaphore: semaphore is not ready [0x1][0x300]
[   23.139869] codec_semaphore: semaphore is not ready [0x1][0x300]
[   23.185105] codec_semaphore: semaphore is not ready [0x1][0x300]
[   23.231767] codec_semaphore: semaphore is not ready [0x1][0x300]
[   23.995341] cs: IO port probe 0x100-0x3af: clean.
[   24.041916] cs: IO port probe 0x100-0x3af: clean.
[   24.189370] cs: IO port probe 0x3e0-0x4ff: clean.
[   24.233240] cs: IO port probe 0x3e0-0x4ff: clean.
[   24.275387] cs: IO port probe 0x820-0x8ff: clean.
[   24.322868] cs: IO port probe 0x820-0x8ff: clean.
[   24.364650] cs: IO port probe 0xc00-0xcf7: clean.
[   24.402739] cs: IO port probe 0xc00-0xcf7: clean.
[   24.441138] cs: IO port probe 0xa00-0xaff: clean.
[   24.478657] cs: IO port probe 0xa00-0xaff: clean.
[   24.520012] AC'97 1 does not respond - RESET
[   24.556644] codec_semaphore: semaphore is not ready [0x1][0x300]
[   24.593553] codec_semaphore: semaphore is not ready [0x1][0x300]
[   24.628550] AC'97 1 access is not valid [0x], removing mixer.
[   24.663648] Unable to initialize codec #1
[   24.698342] ACPI: PCI interrupt for device :00:01.6 disabled
[   24.732436] Intel ICH Modem: probe of :00:01.6 failed with error -5
[   24.767989] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[   26.605406] EXT3 FS on hda1, internal journal
[   27.105546] loop: module loaded
[   27.426215] device-mapper: uevent: version 1.0.3
[   27.467167] 

Bug#497382: kvkcard segfaults when reading eGK

[Karsten Hilbert]

On Sat, Sep 06, 2008 at 08:38:52PM +0200, Micha Lenk wrote:

  I installed libchipcard-dev but even that didn't give much
  better results than this:
 
 Indeed, the backtrace isn't very helpful. Can you please try again to
 get a backtrace with these packages from [1] installed? Those packages
 are built with debugging information enabled and without being stripped
 during package build process.
 
 1. http://micha.lenk.info/debian/experimental/

- downloaded all of the above debs
- installed with dpkg -i -R from a directory
- /etc/init.d/libchipcard-tools stop / start

This is what gdb gives:

(gdb) run
Starting program: /usr/bin/kvkcard read -v -v
[Thread debugging using libthread_db enabled]
Connecting to server.
Connected.
Waiting for card...
Found a card.
Opening card as KVK card.
Card is not a KVK card.
Opening card as EGK card.
Card is a EGK card, handling it.
Writing data to file
Version:libchipcard4-4.2.0.0stable
Datum:08.09.2008
Zeit:09:33:05
Lesertyp:tow_cdm
Kartentyp:Elektronische Gesundheitskarte
[New Thread 0xb7aeb6b0 (LWP 12460)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7aeb6b0 (LWP 12460)]
0xb7eb3ac9 in LC_HIInsuranceData_GetInstitutionName (st=0x21) at 
hiinsurancedata.c:171
171 hiinsurancedata.c: No such file or directory.
in hiinsurancedata.c
(gdb) bt
#0  0xb7eb3ac9 in LC_HIInsuranceData_GetInstitutionName (st=0x21) at 
hiinsurancedata.c:171
#1  0x08049b7b in storeCardData (fname=0x0, cd=0x8a84828, dosMode=value 
optimized out,
cardType=0x804be50 Elektronische Gesundheitskarte, cardNumber=0x0, 
pData=0xb7aeb6b0, iData=0x21) at read.c:53
#2  0x0804abb2 in handleEgkCard (card=0x8a84828, dbArgs=0x89875a8) at read.c:237
#3  0x0804b153 in handleCard (card=0x8a84828, dbArgs=0x89875a8) at read.c:316
#4  0x0804b2fb in kvkRead (cl=0x8a81d00, dbArgs=0x89875a8) at read.c:384
#5  0x0804b7f4 in main (argc=Cannot access memory at address 0x0
) at main.c:302
(gdb)


Much more informative  :-)

Martin, this is my *second* eGK card - which the AOK
probably sent me for a reason - perhaps there's some other /
more functionality active at the card level ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



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

Bug#497382: libchipcard-tools: experimental fails reading eGK

[Karsten Hilbert]

On Tue, Sep 02, 2008 at 12:43:31AM +0200, Micha Lenk wrote:

 can you please provide a backtrace of kvkcard?

Sure :-)

I installed libchipcard-dev but even that didn't give much
better results than this:

merkur:~# gdb --args kvkcard read -v -v
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
(no debugging symbols found)
(gdb) run
Starting program: /usr/bin/kvkcard read -v -v
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
(no debugging symbols found)
Connecting to server.
Connected.
Waiting for card...
Waiting for card to be inserted: Started.
Waiting for card to be inserted: 4000 of 2
Waiting for card to be inserted: Finished.
Found a card.
Opening card as KVK card.
Card is not a KVK card.
Opening card as EGK card.
Card is a EGK card, handling it.
Writing data to file
Version:libchipcard4-4.2.0.0stable
Datum:02.09.2008
Zeit:12:14:47
Lesertyp:tow_cdm
Kartentyp:Elektronische Gesundheitskarte
[New Thread 0xb7ae76b0 (LWP 4684)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7ae76b0 (LWP 4684)]
0xb7eafac9 in LC_HIInsuranceData_GetInstitutionName () from 
/usr/lib/libchipcardc.so.2
(gdb) bt
#0  0xb7eafac9 in LC_HIInsuranceData_GetInstitutionName () from 
/usr/lib/libchipcardc.so.2
#1  0x08049b7b in ?? ()
#2  0x0021 in ?? ()
#3  0x0804c0e3 in ?? ()
#4  0x0804be50 in ?? ()
#5  0x0804c0a7 in ?? ()
#6  0x0a01b938 in ?? ()
#7  0x in ?? ()
(gdb)

Hope that helps,
Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



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

Bug#382190: python-imaging-sane: missing dependency on numarray.libnumarray

[Karsten Hilbert]

Package: python-imaging-sane
Version: 1.1.5-10
Severity: serious
Justification: renders package unusable in certain circumstances

It segfaults (?) due to not finding numarray -- which does not seem to be
listed as a dependancy. It seems it previously used numpy instead.

[EMAIL PROTECTED]:~$ python
Python 2.3.5 (#2, Jul 30 2006, 15:57:01)
[GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2
Type help, copyright, credits or license for more information.
 import sane
ImportError: No module named numarray.libnumarray
Fatal Python error: numarray.libnumarray failed to import... exiting.

Abgebrochen
[EMAIL PROTECTED]:~$

apt-get install python-numarray fixes things.


Karsten

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-k7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages python-imaging-sane depends on:
ii  python2.3.5-11   An interactive high-level object-o
ii  python-central0.5.1  register and build utility for Pyt
ii  python-imaging1.1.5-10   Python Imaging Library

Versions of packages python-imaging-sane recommends:
ii  python-tk 2.4.3-3Tkinter - Writing Tk applications 

-- no debconf information


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

Bug#344333: libextractor-python: fails unit test

[Karsten Hilbert]

Package: libextractor-python
Version: 0.5.1-2
Severity: grave
Justification: renders package unusable

Script started on Mi 21 Dez 2005 22:06:12 CET
[EMAIL PROTECTED]:~/tmp$ python ./extract.py
Traceback (most recent call last):
  File ./extract.py, line 27, in ?
xtract = extractor.Extractor()
AttributeError: 'module' object has no attribute 'Extractor'
[EMAIL PROTECTED]:~/tmp$ exit

Script done on Mi 21 Dez 2005 22:06:24 CET

The extract.py was taken from

 libextractor-python-0.5.4.tar.gz

from the homepage of libextractor.

Karsten

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-k7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages libextractor-python depends on:
ii  libc6 2.3.5-8GNU C Library: Shared libraries an
ii  libextractor1c2a  0.5.8-1extracts meta-data from files of a
ii  python2.3.5-3An interactive high-level object-o

libextractor-python recommends no packages.

-- no debconf information


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