Bug#1063581: gnumed-client: checked by upstream

[Karsten Hilbert]

Package: gnumed-client
Version: 1.8.18+dfsg-1
Followup-For: Bug #1063581

I have checked and from an upstream point of view the dependancy
can be changed from p7zip-full to 7zip.

Thanks,
Karsten


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 6.7-686-pae (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnumed-client depends on:
ii  aspell   0.60.8-4+b1
ii  file 1:5.44-3
ii  gnumed-common1.8.18+dfsg-1
ii  hunspell 1.7.1-1
ii  imagemagick  8:6.9.11.60+dfsg-1.6
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.6
ii  ispell   3.4.05-1
ii  python3  3.11.2-1+b1
ii  python3-enchant  3.2.2-1
ii  python3-gnuplot  1.8-8
ii  python3-hl7  0.4.5-1
ii  python3-httplib2 0.20.4-3
ii  python3-lxml 4.9.2-1+b1
ii  python3-psutil   5.9.4-1+b1
ii  python3-pyudev   0.24.0-1
ii  python3-wxgtk4.0 4.2.0+dfsg-3
ii  texlive-latex-base   2022.20230122-3

Versions of packages gnumed-client recommends:
ii  aeskulap   0.2.2-beta2+git20190406.ef77f01-4+b1
ii  amide  1.0.6-1
ii  audiofile-tools0.3.6-5+b1
ii  chktex 1.7.8-1
ii  chromium [www-browser] 121.0.6167.160-1~deb12u1
ii  dcmtk  3.6.7-8+b1
ii  extract1:1.11-7
ii  firefox-esr [www-browser]  115.7.0esr-1~deb12u1
ii  gnumed-doc 1.8.18+dfsg-1
ii  gpg2.2.40-1.1
ii  gtklp  1.3.4-3+b1
ii  konqueror [www-browser]4:22.12.3-1
ii  lacheck1.26-17
ii  libimage-exiftool-perl 12.57+dfsg-1
ii  libreoffice-writer 4:7.4.7-1+deb12u1
ii  lynx [www-browser] 2.9.0dev.12-1
ii  p7zip-full 16.02+dfsg-8
ii  pdftk-java 3.3.2-1
ii  poppler-utils  22.12.0-2+b1
ii  python3-docutils   0.19+dfsg-6
ii  python3-pyqrcode   1.2.1-4
ii  python3-unidecode  1.3.6-1
ii  python3-vobject0.9.6.1-2
ii  qpdf   11.3.0-1+deb12u1
ii  systemd-timesyncd  252.22-1~deb12u1
ii  texlive-latex-extra2022.20230122-4
ii  texlive-latex-recommended  2022.20230122-3
ii  w3m [www-browser]  0.5.3+git20230121-2
ii  wgerman-medical20220425-1
ii  xdg-utils  1.1.3-4.1
ii  xmedcon0.23.0-gtk3+dfsg-1
ii  xsane  0.999-12+b1

Versions of packages gnumed-client suggests:
pn  autokey-qt | autokey-gtk
ii  edfbrowser  2.00+dfsg-1
ii  entangle3.0-3
ii  gnumed-server   22.28-1
pn  incron  
ii  kolourpaint 4:22.12.3-1
pn  konsolekalendar 
pn  korganizer  
ii  libchipcard-tools   5.1.6-1+b1
ii  nvram-wakeup1.1-4+b1
ii  python3-uno 4:7.4.7-1+deb12u1
ii  qrisk2  0.1.20150729-5
pn  shutdown-at-night   
pn  wakeonlan | etherwake | gwakeonlan  

-- no debconf information

Bug#1063669: gnumed-client-de: please demote libchipcard-tools from dep: to rec:

[Karsten Hilbert]

Package: gnumed-client-de
Version: latest
Severity: normal

As the Subject says -- prompted by

1062249: libchipcard: NMU diff for 64-bit time_t transition
 https://bugs.debian.org/1062249
1062362: libgwenhywfar: NMU diff for 64-bit time_t transition
 https://bugs.debian.org/1062362

I would like to ask for libchipcard-tools to be set
to Recommends: instead of Depends:.

Thanks,
Karsten
(upstream)


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 6.7-686-pae (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnumed-client-de depends on:
ii  adduser3.134
ii  gnumed-client  1.8.18+dfsg-1
ii  libchipcard-tools  5.1.6-1+b1

Versions of packages gnumed-client-de recommends:
ii  dmtx-utils   0.7.6-1.1+b1
pn  hunspell-de-med  
ii  iec16022 0.2.4-3
ii  wgerman-medical  20220425-1

Versions of packages gnumed-client-de suggests:
pn  libctapimkt1  

Bug#1005388: gnumed-client: new upstream available

[Karsten Hilbert]

Package: gnumed-client
Version: 1.8.6+dfsg-1
Severity: wishlist
Tags: upstream

Dear maintainers,

there's a new upstream version available.

Packaging would be greatly appreciated.

Thanks,
Karsten



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

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

Versions of packages gnumed-client depends on:
ii  aspell   0.60.8-3
ii  file 1:5.39-3
ii  gnumed-common1.8.6+dfsg-1
ii  hunspell 1.7.0-3
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  ispell   3.4.02-2
ii  python3  3.9.2-3
ii  python3-enchant  3.2.0-1
ii  python3-gnuplot  1.8-8
ii  python3-hl7  0.4.1-1
ii  python3-httplib2 0.18.1-3
ii  python3-lxml 4.6.3+dfsg-0.1
ii  python3-psutil   5.8.0-1
ii  python3-pyudev   0.22.0-2
ii  python3-wxgtk4.0 4.0.7+dfsg-10
ii  texlive-latex-base   2020.20210202-3

Versions of packages gnumed-client recommends:
ii  aeskulap0.2.2-beta2+git20190406.ef77f01-3+b1
ii  amide   1.0.5-15
ii  audiofile-tools 0.3.6-5
ii  chktex  1.7.6-4
ii  dcmtk   3.6.5-1
ii  extract 1:1.11-2
ii  firefox [www-browser]   88.0.1-1
ii  firefox-esr [www-browser]   78.15.0esr-1~deb11u1
ii  ginkgocadx  3.8.8-5+b1
ii  gnumed-doc  1.8.6+dfsg-1
ii  gpg 2.2.27-2
ii  gtklp   1.3.1-1
ii  konqueror [www-browser] 4:20.12.0-4
ii  lacheck 1.26-17
ii  libimage-exiftool-perl  12.16+dfsg-2
ii  libreoffice-writer  1:7.0.4-4+deb11u1
ii  ntp 1:4.2.8p15+dfsg-1
ii  p7zip-full  16.02+dfsg-8
pn  pdftk   
ii  poppler-utils   20.09.0-3.1
ii  printer-driver-cups-pdf [cups-pdf]  3.0.1-9
ii  python3-docutils0.16+dfsg-4
ii  python3-pyqrcode1.2.1-4
ii  python3-unidecode   1.2.0-1
ii  python3-vobject 0.9.6.1-0.2
ii  qpdf10.1.0-1
ii  texlive-latex-extra 2020.20210202-3
ii  texlive-latex-recommended   2020.20210202-3
ii  w3m [www-browser]   0.5.3+git20210102-6
ii  wgerman-medical 20160103-5
ii  xdg-utils   1.1.3-4.1
ii  xmedcon 0.16.3+dfsg-1
ii  xsane   0.999-10

Versions of packages gnumed-client suggests:
pn  autokey-qt | autokey-gtk
ii  edfbrowser  1.81+dfsg-1
ii  entangle3.0-1+b1
pn  freediams   
pn  gimp | kolourpaint4 
ii  gnumed-server   22.15-1
pn  incron  
pn  konsolekalendar 
pn  korganizer  
ii  libchipcard-tools   5.1.5rc2-7
ii  nvram-wakeup1.1-4+b1
pn  pgadmin3
ii  python3-uno 1:7.0.4-4+deb11u1
ii  qrisk2  0.1.20150729-5
pn  shutdown-at-night   
pn  wakeonlan | etherwake | gwakeonlan  

-- no debconf information

Bug#1003158: [pkg-apparmor] Bug#1003158: apparmor: tunables/home seems to have wrong order of variables

[Karsten Hilbert]

Am Wed, Jan 05, 2022 at 09:13:12PM +0100 schrieb Christian Boltz:

> AppArmor rules are in most cases declarative so that the order doesn't
> matter (exception: before you can extend a variable with "+=" you have
> to initialize it with "=").
>
> The current definition is technically not a bug, "just" confusing.

I agree it is not *technically* a bug.

> However, I agree that defining @{HOMEDIRS} before using it would make
> sense to make it less confusing for human parsers ;-)

Nevertheless, intent-wise it is because it also makes @{HOME}
not include anything from /home/ because @{HOMEDIRS} is
undefined when @{HOME} is set up ?

> Since the change is more cosmetic,

Unless I misunderstand apparmor profile logic it is not
purely cosmetic. It excludes "/home/*/" from @{HOME}.

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

Bug#1003158: apparmor: tunables/home seems to have wrong order of variables

[Karsten Hilbert]

Package: apparmor
Version: 2.13.6-10
Severity: important

Dear Maintainers,

there seems to be a order-logic bug in

/etc/apparmor.d/tunables/home

That profile defines @{HOME} first:

@{HOME}=@{HOMEDIRS}/*/ /root/

and *later* defines @{HOMEDIRS}:

@{HOMEDIRS}=/home/

It seems that either the order of definitions needs to be switched or
else the second definition should be

@{HOMEDIRS}+=/home/ #(note the + sign)

?  Or am I missing something.

Thanks,
Karsten


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

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

Versions of packages apparmor depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.33-1
ii  lsb-base   11.1.0

apparmor recommends no packages.

Versions of packages apparmor suggests:
pn  apparmor-profiles-extra  
pn  apparmor-utils   

-- debconf information:
  apparmor/homedirs:

Bug#988596: akonadi-server: bug still exists

[Karsten Hilbert]

Package: akonadi-server
Version: 4:20.08.3-3
Followup-For: Bug #988596


Dear Maintainers,

after an apt full-upgrade from Buster to Bullseye akonadiserver now has an
apparmor profile. That profile seems to prevent it from starting up, as
witnessed by DENY messages in the system log.

Likely, this happens because I have relocated home dirs:

<-->/home/
<--><-->user1 -link-> /somewhere/else/home.user1/
<--><-->user2 -link-> /somewhere/else/home.user2/
<--><-->...

and apparmor seems to not consider the link location as allowed via the
"@xdg_data_home/akonadi/" rules.

For the time being I have set the profile to complain mode but what is
the suggested way forward ?

Thanks,
Karsten


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

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

Versions of packages akonadi-server depends on:
ii  akonadi-backend-mysql4:20.08.3-3
ii  akonadi-backend-postgresql   4:20.08.3-3
ii  libaccounts-qt5-11.16-2
ii  libc62.33-1
ii  libgcc-s110.2.1-6
ii  libkf5akonadiprivate5abi2 [libkf5akonadiprivate5-20.08]  4:20.08.3-3
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-20.08]  4:20.08.3-3
ii  libkf5configcore55.78.0-4
ii  libkf5coreaddons55.78.0-4
ii  libkf5crash5 5.78.0-3
ii  libkf5i18n5  5.78.0-2
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5dbus5  5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5network5   5.15.2+dfsg-9
ii  libqt5sql5   5.15.2+dfsg-9
ii  libqt5widgets5   5.15.2+dfsg-9
ii  libqt5xml5   5.15.2+dfsg-9
ii  libstdc++6   10.2.1-6

akonadi-server recommends no packages.

Versions of packages akonadi-server suggests:
ii  akonadi-backend-mysql   4:20.08.3-3
ii  akonadi-backend-postgresql  4:20.08.3-3
pn  akonadi-backend-sqlite  

-- no debconf information

Bug#987063: gwenview: looses image metadata on jpg rotation

[Karsten Hilbert]

Am Sat, Apr 17, 2021 at 12:54:23PM +0900 schrieb Norbert Preining:

> On Fri, 16 Apr 2021, Nicholas D Steeves wrote:
> > Justification: loss of exif metadata.  A photographer would say "grave 
> > severity"!
>
> Uploaded a fixed version.

Works for me again.

Thanks !

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

Bug#987063: gwenview: looses image metadata on jpg rotation

[Karsten Hilbert]

Package: gwenview
Version: 4:20.12.3-1
Severity: normal
Tags: upstream

This release started to drop metadata from JPEG files after rotating
them. I do believe the following upstream commit is the culprit:


https://invent.kde.org/graphics/gwenview/commit/a401e66621bcffbdc75048d9eaded1a5f5a67137

because it "unconditionally" saves JPEGs thereby overwriting them w/o
carrying over metadata :(

Thanks,
Karsten

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

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

Versions of packages gwenview depends on:
ii  kinit  5.78.0-2
ii  kio5.78.0-4
ii  libc6  2.31-11
ii  libcfitsio93.490-3
ii  libexiv2-270.27.3-3
ii  libgcc-s1  10.2.1-6
ii  libjpeg62-turbo1:2.0.6-4
ii  libkf5activities5  5.78.0-2
ii  libkf5baloo5   5.78.0-3
ii  libkf5completion5  5.78.0-3
ii  libkf5configcore5  5.78.0-4
ii  libkf5configgui5   5.78.0-4
ii  libkf5configwidgets5   5.78.0-2
ii  libkf5coreaddons5  5.78.0-4
ii  libkf5filemetadata35.78.0-2
ii  libkf5i18n55.78.0-2
ii  libkf5iconthemes5  5.78.0-2
ii  libkf5itemmodels5  5.78.0-2
ii  libkf5itemviews5   5.78.0-2
ii  libkf5jobwidgets5  5.78.0-2
ii  libkf5kdcraw5  20.12.0-1
ii  libkf5kiocore5 5.78.0-4
ii  libkf5kiofilewidgets5  5.78.0-4
ii  libkf5kiowidgets5  5.78.0-4
ii  libkf5kipi32.0.0   4:20.12.1-1
ii  libkf5notifications5   5.78.0-2
ii  libkf5parts5   5.78.0-3
ii  libkf5purpose-bin  5.78.0-2
ii  libkf5purpose5 5.78.0-2
ii  libkf5service-bin  5.78.0-2
ii  libkf5service5 5.78.0-2
ii  libkf5solid5   5.78.0-2
ii  libkf5widgetsaddons5   5.78.0-2
ii  libkf5xmlgui5  5.78.0-2
ii  liblcms2-2 2.12~rc1-2
ii  libphonon4qt5-44:4.11.1-3
ii  libpng16-161.6.37-3
ii  libqt5core5a   5.15.2+dfsg-5
ii  libqt5dbus55.15.2+dfsg-5
ii  libqt5gui5 5.15.2+dfsg-5
ii  libqt5printsupport55.15.2+dfsg-5
ii  libqt5svg5 5.15.2-2
ii  libqt5widgets5 5.15.2+dfsg-5
ii  libqt5x11extras5   5.15.2-2
ii  libstdc++6 10.2.1-6
ii  libtiff5   4.2.0-1
ii  libx11-6   2:1.7.0-2
ii  perl   5.32.1-3
ii  phonon4qt5 4:4.11.1-3

Versions of packages gwenview recommends:
pn  kamera 
ii  kio-extras 4:20.12.2-1
ii  qt5-image-formats-plugins  5.15.2-2

gwenview suggests no packages.

-- no debconf information

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#979247: user-manager: holding back upgrade

[Karsten Hilbert]

Package: user-manager
Version: 4:5.19.5-3
Severity: wishlist
Tags: newcomer

Dear Maintainers,

may I kindly ask for 5.20-targeted recompilation ?

Many thanks for considering !

Karsten Hilbert


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

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

Versions of packages user-manager depends on:
ii  accountsservice   0.6.55-3
ii  kio   5.77.0-3
ii  libc6 2.31-6
ii  libcrypt1 1:4.4.17-1
ii  libkf5authcore5   5.77.0-3
ii  libkf5configcore5 5.77.0-2
ii  libkf5configwidgets5  5.77.0-2
ii  libkf5coreaddons5 5.77.0-2
ii  libkf5i18n5   5.77.0-2
ii  libkf5kiocore55.77.0-3
ii  libkf5widgetsaddons5  5.77.0-4
ii  libpwquality1 1.4.4-1
ii  libqt5core5a  5.15.2+dfsg-2
ii  libqt5dbus5   5.15.2+dfsg-2
ii  libqt5gui55.15.2+dfsg-2
ii  libqt5widgets55.15.2+dfsg-2
ii  libstdc++610.2.1-3

user-manager recommends no packages.

user-manager suggests no packages.

-- no debconf information

Bug#974212: Acknowledgement (kwin-x11 crashes, windows missing decorations)

[Karsten Hilbert]

The latest KDE in testing fixes the problem for me.

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

Bug#974529: gnumed-client: new upstream available

[Karsten Hilbert]

Package: gnumed-client
Version: 1.8.3+dfsg-1
Severity: wishlist
Tags: upstream

Dear maintainers,

upstream has released 1.8.4 which fixes a few bugs.

We kindly ask for packaging, as time allows.

This also applies to gnumed-server.

Is there anything we can do to fix the watchfile ?

Thanks,
Karsten

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

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

Versions of packages gnumed-client depends on:
ii  aspell   0.60.8-1
ii  file 1:5.38-5
ii  gnumed-common1.8.3+dfsg-1
ii  hunspell 1.7.0-3
ii  imagemagick  8:6.9.11.24+dfsg-1+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.24+dfsg-1+b1
ii  ispell   3.4.00-8
ii  python3  3.8.6-1
ii  python3-enchant  3.0.1-1
ii  python3-gnuplot  1.8-8
ii  python3-hl7  0.4.1-1
ii  python3-httplib2 0.18.1-1
ii  python3-lxml 4.6.1-1
ii  python3-pip  20.1.1-2
ii  python3-psutil   5.7.3-1
ii  python3-pyudev   0.21.0-3
ii  python3-wxgtk4.0 4.0.7+dfsg-6+b1
ii  texlive-latex-base   2020.20200925-1

Versions of packages gnumed-client recommends:
ii  aeskulap0.2.2-beta2+git20190406.ef77f01-3
ii  amide   1.0.5-13+b1
ii  audiofile-tools 0.3.6-5
ii  chktex  1.7.6-3
ii  dcmtk   3.6.4-2.1+b1
ii  elinks [www-browser]0.13.2-1
ii  extract 1:1.10-1
ii  firefox-esr [www-browser]   78.3.0esr-2
ii  ginkgocadx  3.8.8-4
ii  gnumed-doc  1.8.3+dfsg-1
ii  gpg 2.2.20-1
ii  gtklp   1.3.1-1
ii  konqueror [www-browser] 4:20.04.3-1
ii  lacheck 1.26-17
ii  libimage-exiftool-perl  12.09+dfsg-1
ii  libreoffice-writer  1:7.0.3-3
ii  ntp 1:4.2.8p15+dfsg-1
ii  p7zip-full  16.02+dfsg-8
pn  pdftk   
ii  poppler-utils   20.09.0-3
ii  printer-driver-cups-pdf [cups-pdf]  3.0.1-6
ii  python3-docutils0.16+dfsg-3
ii  python3-pyqrcode1.2.1-4
ii  python3-unidecode   1.1.1-3
ii  python3-vobject 0.9.6.1-0.2
ii  qpdf10.0.3-1
ii  texlive-latex-extra 2020.20200925-1
ii  texlive-latex-recommended   2020.20200925-1
ii  w3m [www-browser]   0.5.3-38+b1
ii  wgerman-medical 20160103-4
ii  xdg-utils   1.1.3-2
ii  xmedcon 0.16.2+dfsg-1
ii  xsane   0.999-9

Versions of packages gnumed-client suggests:
pn  autokey-qt | autokey-gtk
ii  edfbrowser  1.79+dfsg-1
ii  entangle3.0-1+b1
pn  freediams   
pn  gimp | kolourpaint4 
ii  gnumed-server   22.13-1
ii  incron  0.5.12-2
pn  konsolekalendar 
pn  korganizer  
ii  libchipcard-tools   5.1.5rc2-4
ii  nvram-wakeup1.1-4+b1
pn  pgadmin3
ii  python3-uno 1:7.0.3-3
ii  qrisk2  0.1.20150729-5
pn  shutdown-at-night   
pn  wakeonlan | etherwake | gwakeonlan  

-- no debconf information

Bug#974212: kwin-x11 crashes, windows missing decorations

[Karsten Hilbert]

Package: kwin-x11
Version: 4:5.17.5-4
Severity: important

Plama desktop shows but applications lack their window decoration and are
only partially responsive. The taskbar looses auto-hide functionality
(not the setting).

This is similar to #864222 which also has a followup from Nov 10th 2020.

Karsten


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

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

Versions of packages kwin-x11 depends on:
ii  kwin-common4:5.17.5-4
ii  libc6  2.31-4
ii  libepoxy0  1.5.4-1
ii  libgcc-s1  10.2.0-16
ii  libkf5configcore5  5.74.0-2
ii  libkf5coreaddons5  5.74.0-2
ii  libkf5crash5   5.74.0-2
ii  libkf5i18n55.74.0-3
ii  libkf5quickaddons5 5.74.0-2
ii  libkf5waylandserver5   4:5.74.0-2
ii  libkf5windowsystem55.74.0-2
ii  libkwineffects12   4:5.17.5-4
ii  libkwinglutils12   4:5.17.5-4
ii  libkwinxrenderutils12  4:5.17.5-4
ii  libqt5core5a   5.15.1+dfsg-2
ii  libqt5gui5 5.15.1+dfsg-2
ii  libqt5widgets5 5.15.1+dfsg-2
ii  libqt5x11extras5   5.15.1-2
ii  libstdc++6 10.2.0-16
ii  libx11-6   2:1.6.12-1
ii  libxcb-composite0  1.14-2
ii  libxcb-cursor0 0.1.1-4
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb-randr0  1.14-2
ii  libxcb-render0 1.14-2
ii  libxcb-shape0  1.14-2
ii  libxcb-xfixes0 1.14-2
ii  libxcb11.14-2
ii  libxi6 2:1.7.10-1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- no debconf information

Bug#973612: orthanc: libcivetweb version mismatch

[Karsten Hilbert]

Package: orthanc
Version: 1.8.0+dfsg-1
Severity: important

Dear maintainers,

something is odd. Orthanc won't start up:

 root@hermes:~# systemctl status orthanc.service
 • orthanc.service - Lightweight, RESTful DICOM server for healthcare and 
medical research
  Loaded: loaded (/lib/systemd/system/orthanc.service; enabled; vendor 
preset: enabled)
  Active: failed (Result: exit-code) since Mon 2020-11-02 14:57:04 CET; 
23min ago
Docs: man:orthanc(8)
  https://book.orthanc-server.com/index.html
 Process: 18285 ExecStart=/usr/sbin/Orthanc --logdir=/var/log/orthanc 
/etc/orthanc (code=exited, status=127)
Main PID: 18285 (code=exited, status=127)

 Nov 02 14:57:04 hermes systemd[1]: orthanc.service: Scheduled restart job, 
restart counter is at 5.
 Nov 02 14:57:04 hermes systemd[1]: Stopped Lightweight, RESTful DICOM server 
for healthcare and medical research.
 Nov 02 14:57:04 hermes systemd[1]: orthanc.service: Start request repeated too 
quickly.
 Nov 02 14:57:04 hermes systemd[1]: orthanc.service: Failed with result 
'exit-code'.
 Nov 02 14:57:04 hermes systemd[1]: Failed to start Lightweight, RESTful DICOM 
server for healthcare and medical research.


 journalctl:

  Nov 02 14:57:04 hermes systemd[1]: Started Lightweight, RESTful DICOM server 
for healthcare and medical research.
  Nov 02 14:57:04 hermes Orthanc[18285]: /usr/sbin/Orthanc: error while loading 
shared libraries: libcivetweb.so.1.11.0: cannot open shared object file: No 
such file or directory
  Nov 02 14:57:04 hermes systemd[1]: orthanc.service: Main process exited, 
code=exited, status=127/n/a
  Nov 02 14:57:04 hermes systemd[1]: orthanc.service: Failed with result 
'exit-code'.
  Nov 02 14:57:04 hermes systemd[1]: orthanc.service: Scheduled restart job, 
restart counter is at 5.
  Nov 02 14:57:04 hermes systemd[1]: Stopped Lightweight, RESTful DICOM server 
for healthcare and medical research.
  Nov 02 14:57:04 hermes systemd[1]: orthanc.service: Start request repeated 
too quickly.
  Nov 02 14:57:04 hermes systemd[1]: orthanc.service: Failed with result 
'exit-code'.
  Nov 02 14:57:04 hermes systemd[1]: Failed to start Lightweight, RESTful DICOM 
server for healthcare and medical research.

 Depends: ..., libcivetweb1 (>= 1.12+dfsg), ...

 libcivetweb1:
   Installiert:   1.13+dfsg-2
   Installationskandidat: 1.13+dfsg-2
   Versionstabelle:
  *** 1.13+dfsg-2 990
 990 https://deb.debian.org/debian bullseye/main i386 Packages
 100 /var/lib/dpkg/status

Seems like it is linked against a specific version (1.11.0) while
Depends: says something else (>= 1.12) which is actually fulfilled
(1.13).

Karsten


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

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

Versions of packages orthanc depends on:
ii  adduser3.118
ii  dcmtk  3.6.4-2.1+b1
ii  init-system-helpers1.58
ii  libboost-filesystem1.71.0  1.71.0-7+b1
ii  libboost-iostreams1.71.0   1.71.0-7+b1
ii  libboost-locale1.71.0  1.71.0-7+b1
ii  libboost-regex1.71.0 [libboost-regex1.71.0-icu67]  1.71.0-7+b1
ii  libboost-thread1.71.0  1.71.0-7+b1
ii  libc6  2.31-4
ii  libcivetweb1   1.13+dfsg-2
ii  libcurl4   7.72.0-1
ii  libdcmtk14 3.6.4-2.1+b1
ii  libgcc-s1  10.2.0-15
ii  libjpeg62-turbo1:2.0.5-1.1
ii  libjsoncpp11.7.4-3.1
ii  liblua5.3-05.3.3-1.1+b1
ii  libpng16-161.6.37-3
ii  libpugixml1v5  1.10-1
ii  libsqlite3-0   3.33.0-1
ii  libssl1.1  1.1.1h-1
ii  libstdc++6 10.2.0-15
ii  libuuid1   2.36-3+b1
ii  locales2.31-4
ii  lsb-base   11.1.0
ii  tzdata 2020d-1
ii  zlib1g 1:1.2.11.dfsg-2

orthanc recommends no packages.

orthanc suggests no packages.

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

Bug#972833: intel-media-va-driver: SIGSEGV's on use (vlc, finch for example)

[Karsten Hilbert]

On Fri, Oct 30, 2020 at 10:30:47AM +0100, Sebastian Ramacher wrote:

> > anything I can do or anyone I can prod to improve upon the situation ?
> >
> > If I understand things correctly "some driver" is supposed to
> > reconsider its compile flags for parts of its code (esp. init) ?
>
> Yes, indeed. Until that's fixed, you can force libva to use a specific
> driver by setting the LIBVA_DRIVER environment variable, e.g.
>
> export LIBVA_DRIVER=i965

For the record:

On my system it needs to be "LIBVA_DRIVER_NAME" and "i915",
but, yeah, that helps :-)

I put that into my .bashrc for the time being as

export LIBVA_DRVER_NAME=i915

Thanks !

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

Bug#972637: finch: crashes on startup with "illegal instruction"

[Karsten Hilbert]

On Mon, Oct 26, 2020 at 11:04:42PM +0100, Bernhard Übelacker wrote:

> From wikipedia [1] the pminud instruction at 0x...6fb got
> introduced with sse4.1 which seem not supported from your
> flags line (while on the other side intel says [2] it is a Penryn).

OTOH, apparently wikipedia knows better than Intel itself :-)

https://en.wikipedia.org/wiki/SSE4#Name_confusion

> (Might there be a bios switch?)

Unfortunately not.

Karsten

> [2] 
> https://ark.intel.com/content/www/de/de/ark/products/37253/intel-pentium-processor-t4300-1m-cache-2-10-ghz-800-mhz-fsb.html
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#972637: finch: crashes on startup with "illegal instruction"

[Karsten Hilbert]

Hello Bernhard,

thanks for your work.

I have (also) filed a bug against intel-media-va-driver which
was invovked from VLC. They have forwarded the issue upstream:

https://github.com/intel/libva/issues/466

My CPU is Penryn, so it supports "less" SSE than what's
attempted to be used by the VA driver at which point the
SIGILL occurrs.

> Therefore it would be interesting to know with which CPU you
> are getting this SIGILL (e.g. 'lscpu' or 'cat /proc/cpuinfo').

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 23
model name  : Pentium(R) Dual-Core CPU   T4300  @ 2.10GHz
stepping: 10
microcode   : 0xa0b
cpu MHz : 1545.084
cache size  : 1024 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe nx lm constant_tsc 
arch_perfmon pebs bts cpuid aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 
cx16 xtpr pdcm xsave lahf_lm dtherm
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit
bogomips: 4189.35
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

> Otherwise finch seems not to depend directly from intel-media-va-driver,

Yeah, I certainly wondered about that, too, it being a console app.

> and from the package description if your CPU is older than "Broadwell",
> then you might even not benefit from this package. Therefore a
> workaround might be to uninstall intel-media-va-driver if no
> other dependencies require it?

Other deps do (see vlc above).

The stranger thing is that running vlc from either an xterm
or the desktop environment fails, while clvc only fails when
running under X and does not fail on the console.

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

Bug#972833: intel-media-va-driver: SIGSEGV's on use (vlc, finch for example)

[Karsten Hilbert]

On Sat, Oct 24, 2020 at 10:39:09PM +0200, Sebastian Ramacher wrote:

> > Okt 24 17:56:50 hermes kernel: traps: vlc[27504] trap invalid opcode 
> > ip:89c9d6fb sp:8e550370 error:0 in iHD_drv_video.so[899dc000+3c2000]
>
> Which Intel CPU/GPU do you have? If the instruction is not supported, libva
> shouldn't load the driver for your's.

Architecture:i686
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
Address sizes:   36 bits physical, 48 bits virtual
CPU(s):  2
On-line CPU(s) list: 0,1
Thread(s) per core:  1
Core(s) per socket:  2
Socket(s):   1
Vendor ID:   GenuineIntel
CPU family:  6
Model:   23
Model name:  Pentium(R) Dual-Core CPU   T4300  @ 2.10GHz
Stepping:10
CPU MHz: 1342.405
CPU max MHz: 2100.
CPU min MHz: 1200.
BogoMIPS:4189.84
L1d cache:   64 KiB
L1i cache:   64 KiB
L2 cache:1 MiB
Vulnerability Itlb multihit: KVM: Mitigation: VMX unsupported
Vulnerability L1tf:  Mitigation; PTE Inversion
Vulnerability Mds:   Vulnerable: Clear CPU buffers attempted, no 
microcode; SMT disabled
Vulnerability Meltdown:  Vulnerable
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and 
__user pointer sanitization
Vulnerability Spectre v2:Mitigation; Full generic retpoline, STIBP 
disabled, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort:   Not affected
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep 
mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe nx lm 
constant_tsc arch_perfmon pebs bts cpuid aperfmperf pni dtes64 monitor ds_cpl 
est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dtherm


00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Mobile 4 Series Chipset Integrated 
Graphics Controller
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at fe40 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at dc00 [size=8]
Expansion ROM at 000c [virtual] [disabled] [size=128K]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915
Kernel modules: i915


Does that help ?

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

Bug#972833: intel-media-va-driver: SIGSEGV's on use (vlc, finch for example)

[Karsten Hilbert]

Package: intel-media-va-driver
Version: 20.3.0+dfsg1-1
Severity: important
Tags: upstream

This happens when running vlc (or finch, for that matter):

VLC media player 3.0.11.1 Vetinari (revision 3.0.11.1-0-g52483f3ca2)
[006aabe0] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. 
Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
[991bf220] gl gl: Initialized libplacebo v2.72.0 (API v72)
libva info: VA-API version 1.9.0
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so 
Ungültiger Maschinenbefehl

journalctl -b:

Okt 24 17:56:50 hermes kernel: traps: vlc[27504] trap invalid opcode 
ip:89c9d6fb sp:8e550370 error:0 in iHD_drv_video.so[899dc000+3c2000]

gdb:

ncq@hermes:/media/ncq/SIMMAX/ccc$ gdb --args vlc 
36c3-10961-eng-deu-fra-Boeing_737MAX_Automated_Crashes_sd.mp4
GNU gdb (Debian 9.2-1) 9.2
Copyright (C) 2020 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 vlc...
(No debugging symbols found in vlc)
(gdb) run
Starting program: /usr/bin/vlc 
36c3-10961-eng-deu-fra-Boeing_737MAX_Automated_Crashes_sd.mp4
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
VLC media player 3.0.11.1 Vetinari (revision 3.0.11.1-0-g52483f3ca2)
[New Thread 0xb4b6fb40 (LWP 7805)]
[New Thread 0xb435db40 (LWP 7806)]
[New Thread 0xaff9ab40 (LWP 7807)]
[New Thread 0xa3dffb40 (LWP 7808)]
[New Thread 0xa3bffb40 (LWP 7809)]
[00405be0] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. 
Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
[New Thread 0x9d37bb40 (LWP 7810)]
[New Thread 0x9d027b40 (LWP 7811)]
[Thread 0xa3bffb40 (LWP 7809) exited]
[New Thread 0xa3bffb40 (LWP 7812)]
[New Thread 0xa39ffb40 (LWP 7814)]
[Thread 0xa39ffb40 (LWP 7814) exited]
[New Thread 0xa37f2b40 (LWP 7815)]
[Thread 0xa3dffb40 (LWP 7808) exited]
[Thread 0xa3bffb40 (LWP 7812) exited]
[New Thread 0xa3bffb40 (LWP 7817)]
[New Thread 0x9de08b40 (LWP 7819)]
[New Thread 0x9a5a5b40 (LWP 7820)]
[New Thread 0x99da4b40 (LWP 7821)]
[New Thread 0x995a3b40 (LWP 7822)]
[New Thread 0xa3dffb40 (LWP 7823)]
[New Thread 0xa39ffb40 (LWP 7824)]
[New Thread 0x9d4ffb40 (LWP 7825)]
[Thread 0x9d4ffb40 (LWP 7825) exited]
[New Thread 0x8d40 (LWP 7826)]
[New Thread 0x8d1ffb40 (LWP 7827)]
[New Thread 0x8c9feb40 (LWP 7828)]
[New Thread 0x9d4ffb40 (LWP 7829)]
[Thread 0xa39ffb40 (LWP 7824) exited]
[New Thread 0xa39ffb40 (LWP 7831)]
[New Thread 0x8b7ffb40 (LWP 7832)]
[New Thread 0x8abbeb40 (LWP 7833)]
[New Thread 0x8a3bdb40 (LWP 7834)]
[New Thread 0x89bbcb40 (LWP 7835)]
[New Thread 0x893bbb40 (LWP 7836)]
[9f7c4c20] gl gl: Initialized libplacebo v2.72.0 (API v72)
libva info: VA-API version 1.9.0
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so

Thread 25 "vlc" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x8b7ffb40 (LWP 7832)]
0x86f9d6fb in ?? () from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
(gdb) bt
#0  0x86f9d6fb in ?? () from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
#1  0x86f9fb61 in ?? () from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
#2  0x86ceb0a6 in ?? () from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
#3  0xb7fe5e9c in call_init (l=, argc=argc@entry=2, 
argv=argv@entry=0xb224, env=0xb230) at dl-init.c:72
#4  0xb7fe5fa2 in call_init (env=0xb230, argv=0xb224, argc=2, 
l=) at dl-init.c:30
#5  _dl_init (main_map=, argc=2, argv=0xb224, 
env=0xb230) at dl-init.c:119
#6  0xb7fe92a7 in call_dl_init (closure=0x8b7fe660) at dl-open.c:469
#7  0xb7e9f524 in __GI__dl_catch_exception (exception=, 
operate=, args=) at dl-error-skeleton.c:182
#8  0xb7fea08d in dl_open_worker (a=) at dl-open.c:758
#9  0xb7e9f4c9 in __GI__dl_catch_exception (exception=0x8b7fe790, 
operate=0xb7fe9990 , args=0x8b7fe79c) at dl-error-skeleton.c:208
#10 0xb7fe95e6 in _dl_open (file=0x87752e50 
"/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", mode=-2147479294, 
caller_dlopen=0x8dc67cc3, nsid=, argc=2, argv=0xb224, 
env=0xb230) at dl-open.c:837
#11 0xb7f4a2c8 in dlopen_doit (a=0x8b7fe99c) at dlopen.c:66
#12 0xb7e9f4c9 in __GI__dl_catch_exception (exception=0x8b7fe930, 
operate=0xb7f4a250 , args=0x8b7fe99c) at dl-error-skeleton.c:208
#13 0xb7e9f590 in __GI__dl_catch_error (objname=0xa06fbb0c, 
errstring=0xa06fbb10, mallocedp=0xa06fbb08, 

Bug#972637: Acknowledgement (finch: crashes on startup with "illegal instruction")

[Karsten Hilbert]

Installing the dbg syms for my intel graphics gives a bit more detail:

 Thread 1 "finch" received signal SIGILL, Illegal instruction.

 0xad45d6fb in std::__cxx11::basic_string, 
std::allocator >::compare (this=0x7bcde0, __str="VIDEO_DEC_H264", 
this=0x7bcde0, __str="VIDEO_DEC_H264") at 
/usr/include/c++/10/bits/basic_string.h:2852

 warning: Source file is more recent than executable.

 2852  compare(const basic_string& __str) const

Backtrace:

 #0  0xad45d6fb in std::__cxx11::basic_string, 
std::allocator >::compare (this=0x7bcde0, __str="VIDEO_DEC_H264", 
this=0x7bcde0,
 __str="VIDEO_DEC_H264") at /usr/include/c++/10/bits/basic_string.h:2852
 #1  std::operator< , std::allocator > 
(__rhs="VIDEO_DEC_H264", __lhs="VIDEO_DEC_HEVC") at 
/usr/include/c++/10/bits/basic_string.h:6270
 #2  std::less, 
std::allocator > >::operator() (__y="VIDEO_DEC_H264", 
__x="VIDEO_DEC_HEVC",
this=0xad8c78b0 ::GetCreators[abi:cxx11]()::creators>) at 
/usr/include/c++/10/bits/stl_function.h:386
 #3  std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::_Select1st, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> >, std::less, std::allocator > >, 
std::allocator, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > >::_M_get_insert_unique_pos 
(__k="VIDEO_DEC_HEVC", this=0xad8c78b0 ::GetCreators[abi:cxx11]()::creators>)
 at /usr/include/c++/10/bits/stl_tree.h:2101
 #4  std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)>, 
std::_Select1st, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> >, std::less, std::allocator > >, 
std::allocator, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > 
>::_M_emplace_unique, std::allocator >, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > (
 this=0xad8c78b0 ::GetCreators[abi:cxx11]()::creators>) at 
/usr/include/c++/10/bits/stl_tree.h:2419
 #5  0xad45fb61 in std::map, std::allocator >, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*), std::less, std::allocator > >, 
std::allocator, std::allocator > const, DdiMediaDecode* 
(*)(DDI_DECODE_CONFIG_ATTR*)> > 
>::insert, 
std::allocator >, DdiMediaDecode* (*)(DDI_DECODE_CONFIG_ATTR*)> > 
(__x=..., this=0xad8c78b0 ::GetCreators[abi:cxx11]()::creators>)
 at /usr/include/c++/10/bits/stl_map.h:816
 #6  MediaDdiFactory::RegisterCodec (key="VIDEO_DEC_HEVC")
 at ./media_driver/linux/common/ddi/media_ddi_factory.h:67
 #7  0xad1ab0a6 in __static_initialization_and_destruction_0 (__initialize_p=1, 
__priority=65535) at /usr/include/c++/10/bits/char_traits.h:322
 #8  _GLOBAL__sub_I_media_ddi_decode_hevc.cpp(void) () at 
./media_driver/linux/common/codec/ddi/media_ddi_decode_hevc.cpp:967
 #9  0xb7fe5e9c in call_init (l=, argc=argc@entry=1, 
argv=argv@entry=0xb634, env=0xb63c) at dl-init.c:72
 #10 0xb7fe5fa2 in call_init (env=0xb63c, argv=0xb634, argc=1, 
l=) at dl-init.c:30
 #11 _dl_init (main_map=, argc=1, argv=0xb634, 
env=0xb63c) at dl-init.c:119
 #12 0xb7fe92a7 in call_dl_init (closure=0xbfffe870) at dl-open.c:469
 #13 0xb79a9524 in __GI__dl_catch_exception (exception=, 
operate=, args=) at dl-error-skeleton.c:182
 #14 0xb7fea08d in dl_open_worker (a=) at dl-open.c:758
 #15 0xb79a94c9 in __GI__dl_catch_exception (exception=0xbfffe9a0, 
operate=0xb7fe9990 , args=0xbfffe9ac) at dl-error-skeleton.c:208
 #16 0xb7fe95e6 in _dl_open (file=0x7bc970 
"/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", mode=-2147479294, 
caller_dlopen=0xad918cc3, nsid=, argc=1,
 argv=0xb634, env=0xb63c) at dl-open.c:837
 #17 0xb78652c8 in dlopen_doit (a=0xbfffebac) at dlopen.c:66
 #18 0xb79a94c9 in __GI__dl_catch_exception (exception=0xbfffeb40, 
operate=0xb7865250 , args=0xbfffebac) at dl-error-skeleton.c:208
 #19 0xb79a9590 in __GI__dl_catch_error (objname=0x45d68c, errstring=0x45d690, 
mallocedp=0x45d688, operate=0xb7865250 , args=0xbfffebac)
at dl-error-skeleton.c:227
 #20 0xb7865b11 in _dlerror_run (operate=0xb7865250 , 
args=0xbfffebac) at dlerror.c:170
 #21 0xb7865364 in __dlopen (file=0x7bc970 
"/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", mode=4354) at dlopen.c:87
 #22 0xad918cc3 in ?? () from /usr/lib/i386-linux-gnu/libva.so.2
 #23 0xad919f90 in vaInitialize () from /usr/lib/i386-linux-gnu/libva.so.2
 #24 0xada1b525 in ?? () from /usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
 #25 0xada1bfe7 in ?? () from /usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
 #26 0xada1c3b9 in ?? () from /usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
 #27 0xada15568 in ?? () from /usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so

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

Bug#972637: finch: crashes on startup with "illegal instruction"

[Karsten Hilbert]

Package: finch
Version: 2.13.0-2.2+b1
Severity: important

Dear maintainers,

on startup this happens (taken from systemd journal):

kernel: traps: finch[25048] trap invalid opcode ip:ad38b6fb sp:bfb44fc0 
error:0 in iHD_drv_video.so[ad0ca000+3c2000]

Running under gdb and backtracing:

Thread 1 "finch" received signal SIGILL, Illegal instruction.
 0xad45d6fb in ?? 
() from /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
(gdb) bt
#0  0xad45d6fb in ?? () from 
/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
#1  0xad45fb61 in ?? () from 
/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
#2  0xad1ab0a6 in ?? () from 
/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
#3  0xb7fe5e9c in call_init (l=, argc=argc@entry=1, 
argv=argv@entry=0xb634, env=0xb63c) at dl-init.c:72
#4  0xb7fe5fa2 in call_init (env=0xb63c, argv=0xb634, argc=1, 
l=) at dl-init.c:30
#5  _dl_init (main_map=, argc=1, argv=0xb634, 
env=0xb63c) at dl-init.c:119
#6  0xb7fe92a7 in call_dl_init (closure=0xbfffe870) at dl-open.c:469
#7  0xb79a9524 in __GI__dl_catch_exception (exception=, 
operate=, args=) at dl-error-skeleton.c:182
#8  0xb7fea08d in dl_open_worker (a=) at dl-open.c:758
#9  0xb79a94c9 in __GI__dl_catch_exception (exception=0xbfffe9a0, 
operate=0xb7fe9990 , args=0xbfffe9ac) at dl-error-skeleton.c:208
#10 0xb7fe95e6 in _dl_open (file=0x7bc970 
"/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", mode=-2147479294, 
caller_dlopen=0xad918cc3, nsid=, argc=1, argv=0xb634, 
env=0xb63c) at dl-open.c:837
#11 0xb78652c8 in dlopen_doit (a=0xbfffebac) at dlopen.c:66
#12 0xb79a94c9 in __GI__dl_catch_exception (exception=0xbfffeb40, 
operate=0xb7865250 , args=0xbfffebac) at dl-error-skeleton.c:208
#13 0xb79a9590 in __GI__dl_catch_error (objname=0x45d68c, 
errstring=0x45d690, mallocedp=0x45d688, operate=0xb7865250 , 
args=0xbfffebac) at dl-error-skeleton.c:227
#14 0xb7865b11 in _dlerror_run (operate=0xb7865250 , 
args=0xbfffebac) at dlerror.c:170
#15 0xb7865364 in __dlopen (file=0x7bc970 
"/usr/lib/i386-linux-gnu/dri/iHD_drv_video.so", mode=4354) at dlopen.c:87
#16 0xad918cc3 in ?? () from /usr/lib/i386-linux-gnu/libva.so.2
#17 0xad919f90 in vaInitialize () from 
/usr/lib/i386-linux-gnu/libva.so.2
#18 0xada1b525 in ?? () from 
/usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
#19 0xada1bfe7 in ?? () from 
/usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
#20 0xada1c3b9 in ?? () from 
/usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
#21 0xada15568 in ?? () from 
/usr/lib/i386-linux-gnu/gstreamer-1.0/libgstva.so
#22 0xb7e4d26e in ?? () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#23 0xb7e4f24e in ?? () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#24 0xb7e5d0cd in ?? () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#25 0xb7e5e05b in ?? () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#26 0xb7e5e33e in ?? () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#27 0xb7e5fe8e in gst_update_registry () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#28 0xb7df10be in ?? () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#29 0xb7c7569b in g_option_context_parse () from 
/usr/lib/i386-linux-gnu/libglib-2.0.so.0
#30 0xb7df1d25 in gst_init_check () from 
/usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#31 0x0042e5a8 in finch_sound_init () at ././finch/gntsound.c:383
#32 0x004313ed in gnt_ui_init () at ././finch/gntui.c:68
#33 0xb7ac2c29 in purple_core_init () from /usr/lib/libpurple.so.0
#34 0x0040f344 in init_libpurple (argv=0xb634, argc=1) at 
././finch/finch.c:383
#35 gnt_start (argc=, argv=) at 
././finch/finch.c:434
#36 main (argc=, argv=) at 
././finch/finch.c:456
(gdb)

Thanks,
Karsten



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

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

Versions of packages finch depends on:
ii  libc6  2.31-4
ii  libglib2.0-0   2.66.1-2
ii  libgstreamer1.0-0  1.18.0-3
ii  libncursesw6   6.2+20200918-1
ii  libpurple0 2.13.0-2.2+b1
ii  libtinfo6  6.2+20200918-1
ii  libxml22.9.10+dfsg-6.1
ii  pidgin-data2.13.0-2.2

finch recommends no packages.

Versions of packages finch suggests:
ii  libx11-6  2:1.6.12-1

-- no debconf information

Bug#963738: gnumed-client: new upstream available

[Karsten Hilbert]

Package: gnumed-client
Version: 1.8.1+dfsg-1
Severity: wishlist
Tags: upstream

Dear packagers,

upstream has released 1.8.2 which (among other things) fixes

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

Karsten


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

Kernel: Linux 5.7.0-1-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+deb10u1
ii  gnumed-common1.8.1+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  python3  3.7.3-1
ii  python3-enchant  2.0.0-1
ii  python3-gnuplot  1.8-8
ii  python3-hl7  0.3.4-3
ii  python3-httplib2 0.11.3-2
ii  python3-lxml 4.3.2-1
ii  python3-pip  18.1-5
ii  python3-psutil   5.5.1-1
ii  python3-pyudev   0.21.0-1
ii  python3-wxgtk4.0 4.0.4+dfsg-2
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-esr [www-browser]   68.9.0esr-1~deb10u1
ii  ginkgocadx  3.8.8-1
ii  gnumed-doc  1.8.1+dfsg-1
ii  gpg 2.2.19-2~bpo10+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+deb10u6
ii  ntp 1:4.2.8p12+dfsg-4
ii  p7zip-full  16.02+dfsg-6
pn  pdftk   
ii  poppler-utils   0.71.0-5
ii  printer-driver-cups-pdf [cups-pdf]  3.0.1-5
ii  python3-docutils0.14+dfsg-4
ii  python3-pyqrcode1.2.1-2
pn  python3-unidecode   
ii  python3-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+deb10u1
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
ii  freediams   0.9.4-2
pn  gimp | kolourpaint4 
ii  gnumed-server   22.12-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
ii  python3-uno 1:6.1.5-3+deb10u6
ii  qrisk2  0.1.20150729-4
pn  shutdown-at-night   
pn  wakeonlan | etherwake | gwakeonlan  

-- no debconf information

Bug#960499: python3-psycopg2: fails with "psycopg2.OperationalError: insufficient data in "T" message"

[Karsten Hilbert]

On Wed, May 13, 2020 at 09:13:42AM -0400, Scott Kitterman wrote:

> > Any ideas where else to look ?
>
> It would surprise me if this turned out to be relevant, but since it's
> probably easy to check, I'll toss it out there:
>
> In psycopg2 2.8 the function where the traceback is triggered has been 
> modified
> to use OrderedDict.
>
> "/usr/lib/python3/dist-packages/psycopg2/extras.py", line 142, in
> execute return super(DictCursor, self).execute(query, vars)
>
> It looks like the commit where that change was made it pretty self contained
> [1].  You might try putting the 2.7 version of DictCursor back (reverting that
> commit) and see if the problem persists.
>
> It's kind of a shot in the dark, but one has to start somewhere.

It turned out to be an unholy interaction between threads
inadvertently sharing a connection. Using a connection per
thread solves the issue.

However, the strange parts:

1) The very same code (sharing the connection between
   threads) _does_ work with psycopg2 2.7.

2) psycopg2 states that sharing connections among threads is
   considered to be safe (threadsafety=2). To note, the threads
   do _not_ share cursors.

At any rate, as far as GNUmed is concerned, the issue has
been fixed or, per(!)spectively, worked around so the bug can
be closed.

Maybe one cannot hold open cursors concurrently on the a
transaction shared by threads.

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

Bug#960499: python3-psycopg2: fails with "psycopg2.OperationalError: insufficient data in "T" message"

[Karsten Hilbert]

Package: python3-psycopg2
Version: 2.7.7-1
Severity: important

Dear Maintainers,

users report the following exception:

Traceback (most recent call last):
  File "/usr/share/gnumed/Gnumed/wxpython/gmGuiMain.py", line 3457, in OnInit
if not self.__verify_praxis_branch():
  File "/usr/share/gnumed/Gnumed/wxpython/gmGuiMain.py", line 3687, in 
__verify_praxis_branch
banner = praxis.db_logon_banner
  File "/usr/share/gnumed/Gnumed/business/gmPraxis.py", line 500, in 
_get_db_logon_banner
rows, idx = gmPG2.run_ro_queries(queries = [{'cmd': 'select _(message) from 
cfg.db_logon_banner'}])
  File "/usr/share/gnumed/Gnumed/pycommon/gmPG2.py", line 1547, in 
run_ro_queries
curs.execute(query['cmd'], args)
  File "/usr/lib/python3/dist-packages/psycopg2/extras.py", line 142, in execute
return super(DictCursor, self).execute(query, vars)
psycopg2.OperationalError: insufficient data in "T" message

which looks like a problem at the Python3/C boundary of psycopg2 or even
in the C part of psycopg2 below Python itself  (or even libpq ? - unlikely).

This happens on the following system:

Platform: uname_result(system='Linux', node='X1slapper', 
release='5.4.0-29-generic', version='#33-Ubuntu SMP Wed Apr 29 14:32:27 UTC 
2020', machine='x86_64', processor='x86_64')
Python 3.8.2 (default, Apr 27 2020, 15:53:34) <\n>[GCC 9.3.0] on linux 
(posix)
lsb_release: {'ID': 'Ubuntu', 'DESCRIPTION': 'Ubuntu 20.04 LTS', 
'RELEASE': '20.04', 'CODENAME': 'focal'}
threading: sys.thread_info(name='pthread', lock='semaphore', 
version='NPTL 2.31')

psycopg2 module version: 2.8.4 (dt dec pq3 ext lo64)
PostgreSQL via DB-APImodule "": API level 2.0, thread 
safety 2, parameter style "pyformat"
libpq version (compiled in): 120002
libpq version (loaded now) : 120002

The failing query is rather simple (and probably immaterial):

select _(message) from cfg.db_logon_banner

where _() is a plpgsql function providing a translation lookup.

The very same code works just fine on Python 3.7 / psycopg2 2.7.

Any ideas where else to look ?

Karsten


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

Kernel: Linux 5.6.0-trunk-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 python3-psycopg2 depends on:
ii  libc62.28-10
ii  libpq5   11.7-0+deb10u1
ii  python3  3.7.3-1

python3-psycopg2 recommends no packages.

Versions of packages python3-psycopg2 suggests:
ii  python-psycopg2-doc  2.7.7-1

-- no debconf information

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Wed, Apr 08, 2020 at 07:50:06AM +0200, Sébastien Jodogne wrote:

> Sorry for having overlooked this issue.
>
> I have migrated Karsten's instructions into the "README.Debian" file of
> the "orthanc" package:
> https://salsa.debian.org/med-team/orthanc/-/commit/9f004236c6190a4b3137d358b8de9d0cae498f90

Thanks for that. Do note that those haven't actually been
tested while the attached script *has* been.

Any chance that script can be integrated ?

(just put it in /usr/sbin/ and add a note about it into README.Debian)

Of course, that's a wishlist item, not a request.

Best,
Karsten


> HTH,
> Sébastien-
>
>
> On 7/04/20 23:22, Karsten Hilbert wrote:
> > On Mon, Apr 06, 2020 at 01:43:57PM -0700, tony mancill wrote:
> >
> >> On Fri, Dec 30, 2016 at 12:15:45PM +0100, Karsten Hilbert wrote:
> >>> On Fri, Dec 30, 2016 at 10:57:56AM +0100, Sébastien Jodogne wrote:
> >>>
> >>>> Sorry, my mistake: Preventing Orthanc from starting after an upgrade of 
> >>>> the
> >>>> database schema was on my TODO list... it is not implemented yet. I have
> >>>> just added an issue on the upstream bug tracker to avoid forgetting it:
> >>>> https://bitbucket.org/sjodogne/orthanc/issues/29
> >>>>
> >>>> This feature will be part of forthcoming 1.2.1 release.
> >>>
> >>> Thanks a lot for confirming. I will test when 1.2.1 is out
> >>> and provide a script users can run updating the database
> >>> schema if needed.
> >>
> >> Hello Karsten,
> >>
> >> Debian stable now has version 1.5.6 [1] and the upstream bug report is
> >> marked as resolved [2].  Is a separate update script still needed?  If
> >> not, can this bug report be closed?
> >
> > A separate script is never needed because Orthanc itself can
> > upgrade it's database -- if manually invoked in the right
> > environment.
> >
> > The (attached) script makes it a lot easier for users to do
> > so and it proves (on my machine) that the surprising behaviour
> > (Orthanc being started after a run with --upgrade) is fixed.
> >
> > So, the bug can be closed, regardless of the attached script
> > -- but the attached script is useful to users whenever
> > another database upgrade comes along (which there will,
> > eventually).
> >
> > Best,
> > Karsten
> > --
> > GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
> >

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

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Mon, Apr 06, 2020 at 01:43:57PM -0700, tony mancill wrote:

> On Fri, Dec 30, 2016 at 12:15:45PM +0100, Karsten Hilbert wrote:
> > On Fri, Dec 30, 2016 at 10:57:56AM +0100, Sébastien Jodogne wrote:
> >
> > > Sorry, my mistake: Preventing Orthanc from starting after an upgrade of 
> > > the
> > > database schema was on my TODO list... it is not implemented yet. I have
> > > just added an issue on the upstream bug tracker to avoid forgetting it:
> > > https://bitbucket.org/sjodogne/orthanc/issues/29
> > >
> > > This feature will be part of forthcoming 1.2.1 release.
> >
> > Thanks a lot for confirming. I will test when 1.2.1 is out
> > and provide a script users can run updating the database
> > schema if needed.
>
> Hello Karsten,
>
> Debian stable now has version 1.5.6 [1] and the upstream bug report is
> marked as resolved [2].  Is a separate update script still needed?  If
> not, can this bug report be closed?

A separate script is never needed because Orthanc itself can
upgrade it's database -- if manually invoked in the right
environment.

The (attached) script makes it a lot easier for users to do
so and it proves (on my machine) that the surprising behaviour
(Orthanc being started after a run with --upgrade) is fixed.

So, the bug can be closed, regardless of the attached script
-- but the attached script is useful to users whenever
another database upgrade comes along (which there will,
eventually).

Best,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
#!/bin/bash

#-
# GPLv2 or later, Karsten Hilbert

#set -x

LOGDIR=/var/log/orthanc
LOGFILE=${LOGDIR}/upgrade.log
ARGS="--upgrade --trace /etc/orthanc/"
ORTHANC_BINARY=`which Orthanc`


echo "Stopping Orthanc server..."
echo "#---" &> ${LOGFILE}
systemctl stop orthanc.service &>> ${LOGFILE}
RESULT=$?
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
sleep 1s
if [ ${RESULT} -ne 0 ] ; then
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Cannot stop Orthanc, please inspect the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo "Attempting database upgrade..."
echo "#---" &>> ${LOGFILE}
echo "Running <${ORTHANC_BINARY} ${ARGS}>" >> ${LOGFILE}
sudo -u orthanc ${ORTHANC_BINARY} ${ARGS} &>> ${LOGFILE}
RESULT=$?
if [ ${RESULT} -ne 0 ] ; then
cat ${ORTHANC_LOG} &>> ${LOGFILE}
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Upgrade failed, please check the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo "Restarting Orthanc server..."
sleep 1s
echo "#---" &>> ${LOGFILE}
systemctl start orthanc.service &>> ${LOGFILE}
RESULT=$?
if [ ${RESULT} -ne 0 ] ; then
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Cannot restart Orthanc, please check the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo ""
echo "Seems successful..."
echo "Log: ${LOGFILE}"
echo ""
systemctl status orthanc.service

#-

Bug#954924: gnumed-client: new upstream 1.8.1

[Karsten Hilbert]

Package: gnumed-client
Version: 1.8.0+dfsg-1
Severity: wishlist

There's a new Python3 upstream release: 1.8.1

Karsten

-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 
'stable-updates'), (500, 'unstable'), (500, 'testing'), (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.8.0+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  python3  3.7.3-1
ii  python3-enchant  2.0.0-1
ii  python3-gnuplot  1.8-8
ii  python3-hl7  0.3.4-3
ii  python3-httplib2 0.11.3-2
ii  python3-lxml 4.3.2-1
ii  python3-pip  18.1-5
ii  python3-psutil   5.5.1-1
ii  python3-pyudev   0.21.0-1
ii  python3-wxgtk4.0 4.0.4+dfsg-2
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  ginkgocadx  3.8.8-1
ii  gnumed-doc  1.8.0+dfsg-1
ii  gpg 2.2.19-2~bpo10+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
ii  p7zip-full  16.02+dfsg-6
pn  pdftk   
ii  poppler-utils   0.71.0-5
ii  printer-driver-cups-pdf [cups-pdf]  3.0.1-5
ii  python3-docutils0.14+dfsg-4
ii  python3-pyqrcode1.2.1-2
pn  python3-unidecode   
ii  python3-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
ii  freediams   0.9.4-2
pn  gimp | kolourpaint4 
ii  gnumed-server   22.11-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
ii  python3-uno 1:6.1.5-3+deb10u5
ii  qrisk2  0.1.20150729-4
pn  shutdown-at-night   
pn  wakeonlan | etherwake | gwakeonlan  

-- no debconf information

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#936631: gnumed-server: fixed upstream

[Karsten Hilbert]

Package: gnumed-server
Version: 22.8-1
Followup-For: Bug #936631

Upstream has released 1.8.0/22.11 which supports python3.

Please make python:any -> python3:any.

(note that it has only be tested with py3.7, not py3.8, so maybe versioned ?)

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

Thanks,
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-server depends on:
ii  anacron   2.3-28
ii  bsd-mailx [mail-reader]   8.1.2-0.20180807cvs-1
ii  bzip2 1.0.6-9.2~deb10u1
ii  cron  3.0pl1-134+deb10u1
ii  debconf   1.5.71
ii  gnupg 2.2.19-1
ii  gnupg22.2.12-1+deb10u1
ii  kmail [mail-reader]   4:18.08.3-1
ii  mutt [mail-reader]1.10.1-2.1
ii  openssl   1.1.1d-0+deb10u2
ii  postgresql11+200+deb10u3
ii  postgresql-client 11+200+deb10u3
ii  postgresql-client-11 [postgresql-client]  11.7-0+deb10u1
ii  python2.7.16-1
ii  python-egenix-mxdatetime  3.2.9-1
ii  python-psycopg2   2.7.7-1
ii  rsync 3.1.3-6
ii  sudo  1.8.27-1+deb10u2

Versions of packages gnumed-server recommends:
pn  barman  

Versions of packages gnumed-server suggests:
pn  bacula-console   
ii  orthanc  1.5.6+dfsg-1
ii  orthanc-postgresql   3.2-1
ii  orthanc-webviewer2.5-1
ii  postgresql-contrib   11+200+deb10u3
ii  postgresql-filedump  11.0-1
pn  postgresql-plr   

-- 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#952633: Aw: Bug#952633: gnumed-client: hints for py3 packaging

[Karsten Hilbert]

> > GNUmed v1.8 runs on Python3 / wxPython 4. Version 1.8.0rc3 has just been 
> > released.
>
> https://www.gnumed.de/downloads/client/
>
> has only rc3.

Indeed ?

Karsten

Bug#952633: gnumed-client: hints for py3 packaging

[Karsten Hilbert]

Package: gnumed-client
Version: 1.7.8+dfsg-1
Severity: wishlist


Dear maintainers.

GNUmed v1.8 runs on Python3 / wxPython 4. Version 1.8.0rc3 has just been
released.

It does not need a database *version* different from v1.7 (in other
words, users can simply keep using the exact same database they have been
using with v1.7). However, the bootstrapper has been ported to python3,
too, so a new -server package will be needed as well for new users or for
applying future upgrades to existing databases.

Here is a list of dependencies that need to be changed (I may have missed some):

DEPs:
python:any -> python3:any
python-wxgtk3.0 | python-wxgtk2.8 -> python-wxgtk4.0
python-enchant -> python3-enchant
python-gnuplot -> python3-gnuplot
python-hl7 -> python3-hl7
python-pip -> python3-pip
python-httplib2 -> python3-httplib2
python-psycopg2 -> python3-psycopg2

python-egenix-mxdatetime -> %

% -> python3-pyudev
% -> python3-psutil
% -> python3-lxml

RECs:
python-vobject -> python3-vobject
python-pyqrcode -> python3-pyqrcode
python-uno -> python3-uno

python-faulthandler -> %

% -> p7zip-full
% -> gpg
% -> python3-unidecode
% -> python3-docutils

Also: install gnumed-client.tmpfiles.d.conf into /etc/tmpfiles.d/

The 1.8.0rcN series is a good candidate for preparing the package. I
don't expect any packaging related changes until 1.8.0 proper.

Feel free to ask for clarification if need be.

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

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#936631: gnumed-server: py3 available upstream

[Karsten Hilbert]

Package: gnumed-server
Version: 22.7-1
Followup-For: Bug #936631

There is py3 support available upstream 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-server depends on:
ii  anacron   2.3-28
ii  bsd-mailx [mail-reader]   8.1.2-0.20180807cvs-1
ii  bzip2 1.0.6-9.2~deb10u1
ii  cron  3.0pl1-134
ii  debconf   1.5.71
ii  gnupg 2.2.12-1+deb10u1
ii  gnupg22.2.12-1+deb10u1
ii  kmail [mail-reader]   4:18.08.3-1
ii  mutt [mail-reader]1.10.1-2.1
ii  openssl   1.1.1c-1
ii  postgresql11+200+deb10u2
ii  postgresql-client 11+200+deb10u2
ii  postgresql-client-11 [postgresql-client]  11.5-1+deb10u1
ii  python2.7.16-1
ii  python-egenix-mxdatetime  3.2.9-1
ii  python-psycopg2   2.7.7-1
ii  rsync 3.1.3-6
ii  sudo  1.8.27-1

Versions of packages gnumed-server recommends:
pn  barman  

Versions of packages gnumed-server suggests:
pn  bacula-console   
ii  orthanc  1.5.6+dfsg-1
ii  orthanc-postgresql   3.2-1
ii  orthanc-webviewer2.5-1
ii  postgresql-contrib   11+200+deb10u2
ii  postgresql-filedump  11.0-1
pn  postgresql-plr   

-- no debconf information

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#936630: gnumed-client: upstream has (unreleased) py3 support

[Karsten Hilbert]

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.

Karsten

-- System Information:
Debian Release: 10.0
  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.6+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]   68.0.2-3
ii  freediams   0.9.4-2
ii  ginkgocadx  3.8.8-1
ii  gnumed-doc  1.7.6+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+deb10u3
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#928301: python3-psycopg2: new upstream available

[Karsten Hilbert]

Package: python3-psycopg2
Version: 2.7.7-1
Severity: wishlist
Tags: upstream

Dear maintainers,

there is a new upstream version available.

May I kindly ask for packaging as time permits ?

Thanks,
Karsten


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

Kernel: Linux 5.0.0-trunk-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 python3-psycopg2 depends on:
ii  libc62.28-8
ii  libpq5   11.2-2
ii  python3  3.7.2-1

python3-psycopg2 recommends no packages.

Versions of packages python3-psycopg2 suggests:
ii  python-psycopg2-doc  2.7.7-1

-- no debconf information

Bug#897125: roger-router: there is a new upstream: 2.0

[Karsten Hilbert]

Package: roger-router
Version: 1.8.14-4
Followup-For: Bug #897125

Dear maintainers,

may I kindly ask for an updated version ?

Many thanks !

Karsten


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

Kernel: Linux 4.18.0-2-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 roger-router depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  libappindicator3-1   0.4.92-7
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-8
ii  libcairo-gobject21.16.0-1
ii  libcairo21.16.0-1
ii  libdbusmenu-glib416.04.1+18.04.20171206-1
ii  libebackend-1.2-10   3.30.2-2
ii  libebook-1.2-19  3.30.2-2
ii  libebook-contacts-1.2-2  3.30.2-2
ii  libedata-book-1.2-25 3.30.2-2
ii  libedataserver-1.2-233.30.2-2
ii  libfribidi0  1.0.5-3
ii  libgdata22   0.17.9-2
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libgirepository-1.0-11.58.0-1
ii  libglib2.0-0 2.58.1-2
ii  libgssdp-1.0-3   1.0.2-2
ii  libgtk-3-0   3.24.1-2
ii  libgupnp-1.0-4   1.0.3-1
ii  libjson-glib-1.0-0   1.4.4-1
ii  libnotify4   0.7.7-3
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libpeas-1.0-01.22.0-2
ii  libroutermanager01.8.14-4
ii  libsecret-1-00.18.6-3
ii  libsndfile1  1.0.28-4
ii  libsoup2.4-1 2.64.1-3
ii  libspandsp2  0.0.6+dfsg-0.1
ii  libspeex11.2~rc1.2-1+b2
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libtiff5 4.0.9+git181026-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  roger-router-cli 1.8.14-4

roger-router recommends no packages.

roger-router suggests no packages.

-- no debconf information

Bug#912118: qrisk2: 2017 upstream release

[Karsten Hilbert]

On Sun, Oct 28, 2018 at 02:09:25PM +0100, Andreas Tille wrote:

> I admit I can not find the source for the 2017 release (neither for qrisk2
> nor qrisk3.  Would you mind providing a link or even contact the authors?
> That would be really helpful

Q2-2017: I cannot find a source release either.

Q3: https://qrisk.org/three/src.php

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

Bug#912119: qrisk2: please provide qrisk3

[Karsten Hilbert]

On Sun, Oct 28, 2018 at 01:27:00PM +0100, Andreas Tille wrote:

> thanks for the hints.  Do you think we need both qrisk2 *and* qrisk3?
> I'd prefer to replace qrisk2 by qrisk3 (may be changing the package name
> to qrisk?) or are both different programs with different purpose?

Same purpose, somewhat different program: q3 takes into
account quite a few more variables, and people _may_ have to
recalculate with q2 at some point (say, for litigation matters).

However, they can always do so without having to rely on
Debian offering a qrisk2.

So, technically, it seems the right thing to provide qrisk2
and qrisk3, but q2 will/is supposed to fall into disuse
sooner rather than later, so there goes ...

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

Bug#903595: python3-wxgtk4.0: workaround provided

[Karsten Hilbert]

Package: python3-wxgtk4.0
Version: 4.0.1+dfsg-5
Followup-For: Bug #903595

Scott Talbert provided a workaround which I confirmed fixes the
immediate problem:

apt-get install python3-sip/unstable

Karsten

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

Kernel: Linux 4.17.0-1-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 python3-wxgtk4.0 depends on:
ii  libc6 2.27-3
ii  libgcc1   1:8.1.0-9
ii  libpython3.6  3.6.6-1
ii  libpython3.7  3.7.0-1
ii  libstdc++68.1.0-9
ii  libwxbase3.0-0v5  3.0.4+dfsg-4
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-4
ii  python3   3.6.5-3
ii  python3-sip   4.19.12+dfsg-1
ii  python3-six   1.11.0-2

python3-wxgtk4.0 recommends no packages.

Versions of packages python3-wxgtk4.0 suggests:
pn  wx3.0-doc  

-- no debconf information

Bug#903595: python3-wxgtk4.0: wx import problem

[Karsten Hilbert]

Package: python3-wxgtk4.0
Version: 4.0.1+dfsg-5
Severity: important

ncq@hermes:~$ python3
Python 3.6.6 (default, Jun 27 2018, 14:44:17)
[GCC 8.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/wx/__init__.py", line 17, in 

from wx.core import *
  File "/usr/lib/python3/dist-packages/wx/core.py", line 12, in 
from ._core import *
RuntimeError: the sip module implements API v12.0 to v12.4 but the 
wx._core module requires API v12.5

Karsten

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

Kernel: Linux 4.17.0-1-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 python3-wxgtk4.0 depends on:
ii  libc6 2.27-3
ii  libgcc1   1:8.1.0-9
ii  libpython3.6  3.6.6-1
ii  libpython3.7  3.7.0-1
ii  libstdc++68.1.0-9
ii  libwxbase3.0-0v5  3.0.4+dfsg-4
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-4
ii  python3   3.6.5-3
ii  python3-sip   4.19.8+dfsg-1+b1
ii  python3-six   1.11.0-2

python3-wxgtk4.0 recommends no packages.

Versions of packages python3-wxgtk4.0 suggests:
pn  wx3.0-doc  

-- no debconf information

Bug#894453: wxglade: new upstream (0.8.0) available

[Karsten Hilbert]

Package: wxglade
Version: 0.8.0~a8-1
Severity: wishlist
Tags: upstream

Upstream has released 0.8.0 which officially supports
wxPhoenix/Python3.

Debian tries to reduce the exposure to Python2 so
this wxGlade version would help in porting projects
(we are using wxGlade for GNUmed which needs to
be ported).

May I kindly ask for packaging as your time allows ?

Thanks,
Karsten


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

Kernel: Linux 4.15.0-2-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 wxglade depends on:
ii  python   2.7.14-4
ii  python-wxgtk3.0  3.0.2.0+dfsg-6

wxglade recommends no packages.

wxglade suggests no packages.

-- no debconf information

Bug#890932: python-wxgtk3.0: new upstream (v4) available

[Karsten Hilbert]

Package: python-wxgtk3.0
Version: 3.0.2.0+dfsg-6
Severity: wishlist
Tags: upstream

Dear maintainers,

there's finally a release of wxPython 4 aka wxPhoenix available.

Also, there is a PPA for Xenial which carries wxp4 for both python and
python3:

python-wxgtk4.0:
  Installiert:   4.0.0~rc1.dev3597+5f1ee01-6
  Installationskandidat: 4.0.0~rc1.dev3597+5f1ee01-6
  Versionstabelle:
 *** 4.0.0~rc1.dev3597+5f1ee01-6 500
500 http://ppa.launchpad.net/swt-techie/wxpython4/ubuntu 
xenial/main i386 Packages
100 /var/lib/dpkg/status

Please consider packagin wxPython 4 for Debian as your time allows.

Thanks,
Karsten


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

Kernel: Linux 4.14.0-3-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 python-wxgtk3.0 depends on:
ii  libc6 2.26-6
ii  libgcc1   1:8-20180207-2
ii  libstdc++68-20180207-2
ii  libwxbase3.0-0v5  3.0.3.1+dfsg2-1
ii  libwxgtk3.0-0v5   3.0.3.1+dfsg2-1
ii  python2.7.14-4
ii  python-wxversion  3.0.2.0+dfsg-6

python-wxgtk3.0 recommends no packages.

Versions of packages python-wxgtk3.0 suggests:
pn  wx3.0-doc  

-- no debconf information

Bug#887887: shutter: new upstream 0.94 available

[Karsten Hilbert]

Package: shutter
Version: 0.93.1-2
Severity: wishlist
Tags: upstream

There's a new upstream available from launchpad.net.

Kindly consider an update.

Many thanks,
Karsten


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

Kernel: Linux 4.14.0-3-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 shutter depends on:
ii  imagemagick8:6.9.7.4+dfsg-16
ii  imagemagick-6.q16 [imagemagick]8:6.9.7.4+dfsg-16
ii  libfile-basedir-perl   0.07-1
ii  libfile-copy-recursive-perl0.38-1
ii  libfile-which-perl 1.21-1
ii  libglib-perl   3:1.326-1+b2
ii  libgnome2-canvas-perl  1.002-4+b2
ii  libgnome2-gconf-perl   1.044-6+b2
ii  libgnome2-perl 1.046-3+b2
ii  libgnome2-vfs-perl 1.082-1+b4
ii  libgnome2-wnck-perl0.16-3+b4
ii  libgtk2-imageview-perl 0.05-2+b4
ii  libgtk2-perl   2:1.24992-1+b1
ii  libgtk2-unique-perl0.05-3+b1
ii  libimage-magick-perl [perlmagick]  8:6.9.7.4+dfsg-16
ii  libjson-perl   2.97001-1
ii  libjson-xs-perl3.040-1
ii  liblocale-gettext-perl 1.07-3+b3
ii  libnet-dbus-perl   1.1.0-4+b3
ii  libnet-dropbox-api-perl1.9-1
ii  libpath-class-perl 0.37-1
ii  libproc-processtable-perl  0.53-3
ii  libproc-simple-perl1.32-1
ii  librsvg2-common2.40.20-2
ii  libsort-naturally-perl 1.03-1
ii  libwww-mechanize-perl  1.86-1
ii  libwww-perl6.31-1
ii  libx11-protocol-other-perl 30-1
ii  libx11-protocol-perl   0.56-7
ii  libxml-simple-perl 2.24-1
ii  perlmagick 8:6.9.7.4+dfsg-16
ii  procps 2:3.3.12-3
ii  xdg-utils  1.1.2-1

Versions of packages shutter recommends:
ii  libgoo-canvas-perl 0.06-2+b4
ii  libgtk2-appindicator-perl  0.15-1+b5

Versions of packages shutter suggests:
pn  gnome-web-photo 
ii  libimage-exiftool-perl  10.75-1
pn  libnet-dbus-glib-perl   
pn  nautilus-sendto 

-- no debconf information

Bug#886567: lshw: problem with memory access

[Karsten Hilbert]

Package: lshw
Version: 02.18-0.1
Severity: important
Tags: upstream


Hi,

LSHW suddenly provokes a kernel OOPs.

(Possibly related to #848791 ?)

Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:05:25 hermes kernel: resource sanity check: requesting [mem 
0x000c-0x000d], which spans more than PCI Bus :00 [mem 
0x000d-0x000d window]
Jan 07 18:05:25 hermes kernel: caller pci_map_rom+0x66/0x100 mapping multiple 
BARs
Jan 07 18:08:03 hermes kernel: Bluetooth: Core ver 2.22
Jan 07 18:08:03 hermes kernel: NET: Registered protocol family 31
Jan 07 18:08:03 hermes kernel: Bluetooth: HCI device and connection manager 
initialized
Jan 07 18:08:03 hermes kernel: Bluetooth: HCI socket layer initialized
Jan 07 18:08:03 hermes kernel: Bluetooth: L2CAP socket layer initialized
Jan 07 18:08:03 hermes kernel: Bluetooth: SCO socket layer initialized

Jan 07 18:19:01 hermes kernel: memremap attempted on mixed range 
0x00097000 size: 0x1000
Jan 07 18:19:01 hermes 

Bug#880651: python-psycopg2: kindly provide new upstream 2.7.3.2 (PG 10 / SCRAM support)

[Karsten Hilbert]

Package: python-psycopg2
Version: 2.7.3-1
Severity: wishlist
Tags: upstream

May I kindly ask for an updated package ?

Upstream 2.7.3.2 is released to work with the PG10 client library which
enables things like SCRAM and multiple hosts in connection string.

Thanks,
Karsten

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

Kernel: Linux 4.13.0-1-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)

Versions of packages python-psycopg2 depends on:
ii  libc6   2.24-17
ii  libpq5  10.0-1+b1
ii  python  2.7.14-1

Versions of packages python-psycopg2 recommends:
ii  python-egenix-mxdatetime  3.2.9-1

Versions of packages python-psycopg2 suggests:
ii  python-psycopg2-doc  2.7.3-1

-- no debconf information

Bug#878995: python-egenix-mxdatetime: closing, non-bug

[Karsten Hilbert]

Package: python-egenix-mxdatetime
Followup-For: Bug #878995

I just realized that this is a non-issue because

python-egenix-mx-base-dbg - extension files for the egenix-mx-base 
distribution (debug build)

is provided which does import under python2.7-dbg.

So this report can be closed.

Thanks,
Karsten


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

Kernel: Linux 4.13.0-1-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)

Versions of packages python-egenix-mxdatetime depends on:
ii  libc6  2.24-17
ii  python 2.7.13-2
ii  python-egenix-mxtools  3.2.9-1

python-egenix-mxdatetime recommends no packages.

Versions of packages python-egenix-mxdatetime suggests:
ii  python-egenix-mx-base-dbg [python-egenix-mxdatetime-dbg]  3.2.9-1
ii  python-egenix-mxdatetime-doc  3.2.9-1

-- no debconf information

Bug#878995: python-egenix-mxdatetime: import error in python debug build

[Karsten Hilbert]

Package: python-egenix-mxdatetime
Version: 3.2.9-1
Severity: important

When importing mx.DateTime under python2.7-dbg an import error occurs:

root@hermes:~/bin# python2.7-dbg
Python 2.7.14 (default, Sep 17 2017, 18:50:44)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mx.DateTime
*** You don't have the (right) mxDateTime binaries installed !
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/mx/DateTime/__init__.py", line 
8, in 
from DateTime import *
  File "/usr/lib/python2.7/dist-packages/mx/DateTime/DateTime.py", line 
9, in 
from mxDateTime import *
  File 
"/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/__init__.py", line 13, 
in 
raise ImportError, why
ImportError: 
/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so: 
undefined symbol: Py_InitModule4
[47287 refs]
>>> exit()
[21664 refs]
root@hermes:~/bin# apt-cache policy python-egenix-mxdatetime
python-egenix-mxdatetime:
  Installiert:   3.2.9-1
  Installationskandidat: 3.2.9-1
  Versionstabelle:
 *** 3.2.9-1 990
500 http://httpredir.debian.org/debian stretch/main i386 
Packages
990 http://httpredir.debian.org/debian buster/main i386 Packages
500 http://httpredir.debian.org/debian unstable/main i386 
Packages
100 /var/lib/dpkg/status
root@hermes:~/bin#

Does this module need a recompile ?

Thanks, Karsten


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

Kernel: Linux 4.13.0-1-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)

Versions of packages python-egenix-mxdatetime depends on:
ii  libc6  2.24-17
ii  python 2.7.13-2
ii  python-egenix-mxtools  3.2.9-1

python-egenix-mxdatetime recommends no packages.

Versions of packages python-egenix-mxdatetime suggests:
pn  python-egenix-mxdatetime-dbg  
ii  python-egenix-mxdatetime-doc  3.2.9-1

-- no debconf information

Bug#877920: postgresql-common: pg_upgradecluster 9.6 -> 10 fails (locale problem)

[Karsten Hilbert]

On Sat, Oct 07, 2017 at 05:46:07PM +0200, Karsten Hilbert wrote:

> > Can you check if the upgrade works properly if you remove the
> > "unless"?
> > 
> >  chomp $ctype;
> >  chomp $collate;
> >  print STDERR "$ctype / $collate\n";
> >  return ($ctype, $collate);
> 
> Unfortunately not:
> 
>   root@hermes:~/bin# pg_upgradecluster 9.6 main
>   de_DE.UTF-8 / de_DE.UTF-8
>   0
>   Error: could not get cluster locales

Digging deeper: pg_upgradecluster does

unless ($encoding && $old_lc_ctype && $old_lc_collate) {...}

$encoding comes from get_db_encoding

which also uses psql, which needs -X, too, in PgCommon.pm

Et voila.

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

Bug#877920: postgresql-common: pg_upgradecluster 9.6 -> 10 fails (locale problem)

[Karsten Hilbert]

On Sat, Oct 07, 2017 at 04:40:24PM +0200, Christoph Berg wrote:

> Can you check if the upgrade works properly if you remove the
> "unless"?
> 
>  chomp $ctype;
>  chomp $collate;
>  print STDERR "$ctype / $collate\n";
>  return ($ctype, $collate);

Unfortunately not:

root@hermes:~/bin# pg_upgradecluster 9.6 main
de_DE.UTF-8 / de_DE.UTF-8
0
Error: could not get cluster locales

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

Bug#877920: postgresql-common: pg_upgradecluster 9.6 -> 10 fails (locale problem)

[Karsten Hilbert]

On Sat, Oct 07, 2017 at 05:34:15PM +0200, Christoph Berg wrote:

> Re: Karsten Hilbert 2017-10-07 
> <20171007152609.i4m5zc6yuol4j...@hermes.hilbert.loc>
>>>> return ($ctype, $collate) unless $?;
> > 
> > Actually, isn't this inverted logic ?
> > 
> > It should return(...) unless $? actually is NOT zero ?
> 
> The extracted values should be returned if the last psql call exited
> with status 0. (Yes this function isn't the most pretty one. I'm
> inclined to rewrite the whole psql handling from scratch...)

I'll try to think it through although I am not a perl expert:

psql 

success

now $? is 0 (which is "FALSE")

return ($ctype, $collate) unless $?;

definition: statement unless condition

execute statement unless condition is true

condition: $? which is 0 which is "FALSE"

statement: "return" ($ctype, $collate)

hence: execute "return" unless "FALSE" is true

Won't work, right ?

It should be

return ($ctype, $collate) unless ($? != 0);

or am I mistaken ?

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

Bug#877920: [Pkg-postgresql-public] Bug#877920: postgresql-common: pg_upgradecluster 9.6 -> 10 fails (locale problem)

[Karsten Hilbert]

On Sat, Oct 07, 2017 at 04:40:24PM +0200, Christoph Berg wrote:

> > return ($ctype, $collate) unless $?;

Actually, isn't this inverted logic ?

It should return(...) unless $? actually is NOT zero ?

PSQL(1) 
PostgreSQL 9.6.5 Documentation  
  PSQL(1)

...

EXIT STATUS

psql returns 0 to the shell if it finished normally, 1 if a
fatal error of its own occurs (e.g. out of memory, file not
found), 2 if the connection to the server went bad and the
session was not interactive, and 3 if an error occurred in a
script and the variable ON_ERROR_STOP was set.

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

Bug#877920: postgresql-common: pg_upgradecluster 9.6 -> 10 fails (locale problem)

[Karsten Hilbert]

On Sat, Oct 07, 2017 at 04:40:24PM +0200, Christoph Berg wrote:

> Re: Karsten Hilbert 2017-10-07 
> <20171007132123.7eqyzz7455f5x...@hermes.hilbert.loc>
> > root@hermes:/usr/share/perl5# pg_upgradecluster 9.6 main
> > de_DE.UTF-8 / de_DE.UTF-8
> > Error: could not get cluster locales
> 
> Hmm. At least the uninitialized value warning is gone now.

Yes, it does get one step further.

> > chomp $ctype;
> > chomp $collate;
> > print STDERR "$ctype / $collate\n";
> > return ($ctype, $collate) unless $?;
> 
> I wonder why $? is non-zero even if the $collate extraction worked.

Strangely enough:

chomp $ctype;
chomp $collate;
print STDERR "$ctype / $collate\n";
print STDERR "$?\n";
return ($ctype, $collate) unless $?;
return (undef, undef);

produces this:

root@hermes:~# pg_upgradecluster 9.6 main
de_DE.UTF-8 / de_DE.UTF-8
0
Error: could not get cluster locales

> Can you check if the upgrade works properly if you remove the "unless"?

Will do.

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

Bug#877920: [Pkg-postgresql-public] Bug#877920: postgresql-common: pg_upgradecluster 9.6 -> 10 fails (locale problem)

[Karsten Hilbert]

On Sat, Oct 07, 2017 at 02:11:14PM +0200, Christoph Berg wrote:

> > postgres@hermes:~$ psql -d template1
> > Ausgabeformat ist »wrapped«.
> 
> PgCommon.pm doesn't use 'psql -X' so your (or postgres') .psqlrc might
> be getting in the way. Could you try the upgrade again after moving
> .psqlrc away, or (better) adding an 'X' to PgCommon.pm lines 935 and
> 939?
> 
> open PSQL, '-|', $psql, '-h', $socketdir, '-p', $port, '-XAtc',

Done:

root@hermes:/usr/share/perl5# pg_upgradecluster 9.6 main
de_DE.UTF-8 / de_DE.UTF-8
Error: could not get cluster locales

I also added a print statement:

chomp $ctype;
chomp $collate;
print STDERR "$ctype / $collate\n";
return ($ctype, $collate) unless $?;
return (undef, undef);

which produces the 

de_DE.UTF-8 / de_DE.UTF-8

...

What else can I do ?

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

Bug#877920: postgresql-common: pg_upgradecluster 9.6 -> 10 fails (locale problem)

[Karsten Hilbert]

Thanks for your response !

> could you provide the output of 'psql -l' for the old cluster?

Sure:

postgres@hermes:~$ psql -l
Ausgabeformat ist »wrapped«.
  Liste der Datenbanken
Name| Eigentümer | Kodierung | Sortierfolge | Zeichentyp  |  
Zugriffsprivilegien

++---+--+-+---
 akonadi| postgres   | UTF8  | de_DE.UTF-8  | de_DE.UTF-8 |
 gnumed_v20 | gm-dbo | UTF8  | de_DE.UTF-8  | de_DE.UTF-8 |
 gnumed_v21 | gm-dbo | UTF8  | de_DE.UTF-8  | de_DE.UTF-8 |
 gnumed_v22 | gm-dbo | UTF8  | de_DE.UTF-8  | de_DE.UTF-8 |
 orthanc_db | orthanc| UTF8  | de_DE.UTF-8  | de_DE.UTF-8 |
 postgres   | postgres   | UTF8  | de_DE.UTF-8  | de_DE.UTF-8 |
 template0  | postgres   | UTF8  | de_DE.UTF-8  | de_DE.UTF-8 | 
=c/postgres  +
||   |  | | 
postgres=CTc/postgres
 template1  | postgres   | UTF8  | de_DE.UTF-8  | de_DE.UTF-8 | 
postgres=CTc/postgres+
||   |  | | 
=c/postgres
(8 Zeilen)

> Also, please run
> 
>  SHOW lc_ctype;
>  SHOW lc_collate;
> 
> in the old cluster's template1 database.

postgres@hermes:~$ psql -d template1
Ausgabeformat ist »wrapped«.
psql (10.0, Server 9.6.5)
Geben Sie »help« für Hilfe ein.

template1=# show lc_ctype;
  lc_ctype
-
 de_DE.UTF-8
(1 Zeile)

template1=# show lc_collate;
 lc_collate
-
 de_DE.UTF-8
(1 Zeile)

HTH,
Karsten

Bug#877920: postgresql-common: pg_upgradecluster 9.6 -> 10 fails (locale problem)

[Karsten Hilbert]

Package: postgresql-common
Version: 186
Severity: important

Hello,

when upgrading

Ver Cluster Port Status OwnerData directory   Log file
9.6 main5432 online postgres /var/lib/postgresql/9.6/main 
/var/log/postgresql/postgresql-9.6-main.log

like so:

root@hermes:~/bin# pg_upgradecluster 9.6 main

the following happens:

Use of uninitialized value $ctype in scalar chomp at 
/usr/share/perl5/PgCommon.pm line 947.
Use of uninitialized value $collate in scalar chomp at 
/usr/share/perl5/PgCommon.pm line 948.
Error: could not get cluster locales
root@hermes:~/bin#

Anything else I can provide ?

Karsten


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

Kernel: Linux 4.13.0-trunk-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)

Versions of packages postgresql-common depends on:
ii  adduser   3.116
ii  debconf   1.5.63
ii  init-system-helpers   1.49
ii  lsb-base  9.20170808
ii  postgresql-client-common  186
ii  procps2:3.3.12-3
ii  ssl-cert  1.0.39
ii  ucf   3.0036

Versions of packages postgresql-common recommends:
ii  logrotate  3.11.0-0.1

Versions of packages postgresql-common suggests:
ii  libjson-perl  2.94-1

-- Configuration Files:
/etc/postgresql-common/createcluster.conf changed:
initdb_options = '-k'
ssl = on
cluster_name = '%v/%c'
stats_temp_directory = '/var/run/postgresql/%v-%c.pg_stat_tmp'
log_line_prefix = '%%m [%%p] %%q%%u@%%d '
add_include_dir = 'conf.d'
include_dir '/etc/postgresql-common/createcluster.d'


-- debconf information:
  postgresql-common/catversion-bump:
  postgresql-common/ssl: true
* postgresql-common/obsolete-major:

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

Yesterday I upgraded 4.10.6 to 4.10.7 taken from experimental

Linux hermes 4.10.0-trunk-686-pae #1 SMP Debian 4.10.7-1~exp1 
(2017-03-30) i686 GNU/Linux

and had a bit of hope to see this issue fixed because of

commit f9955dcaceae3a6d5c747b065e1d9da1be50b5ba
Author: Takashi Iwai 
Date:   Wed Jan 11 17:09:50 2017 +0100

fbcon: Fix vc attr at deinit

commit 8aac7f34369726d1a158788ae8aff3002d5eb528 upstream.

fbcon can deal with vc_hi_font_mask (the upper 256 chars) and adjust
the vc attrs dynamically when vc_hi_font_mask is changed at
fbcon_init().  When the vc_hi_font_mask is set, it remaps the attrs 
in
the existing console buffer with one bit shift up (for 9 bits), 
while
it remaps with one bit shift down (for 8 bits) when the value is
cleared.  It works fine as long as the font gets updated after fbcon
was initialized.

However, we hit a bizarre problem when the console is switched to
another fb driver (typically from vesafb or efifb to drmfb).  At
switching to the new fb driver, we temporarily rebind the console to
the dummy console, then rebind to the new driver.  During the
switching, we leave the modified attrs as is.  Thus, the new fbcon
takes over the old buffer as if it were to contain 8 bits chars
(although the attrs are still shifted for 9 bits), and effectively
this results in the yellow color texts instead of the original white
color, as found in the bugzilla entry below.

An easy fix for this is to re-adjust the attrs before leaving the
fbcon at con_deinit callback.  Since the code to adjust the attrs is
already present in the current fbcon code, in this patch, we simply
factor out the relevant code, and call it from fbcon_deinit().

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000619
Signed-off-by: Takashi Iwai 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 

in

https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.10.7

However, no such luck :-)

Perhaps, though, this inspires insight into more
knowledgeable people as to what might be the exact cause ?

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

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

Anything else I can do to get this issue looked into ?

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

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

On Sun, Mar 26, 2017 at 08:18:16PM +0200, Karsten Hilbert wrote:

> One thing I *haven't* tested yet is whether earlier kernel
> would make a difference -- not that I would think but who
> knows.

Just for kicks I booted all kernels installed on this machine
(all prior experimentation was done under 4.10) -- the
console did not get properly configured under any of 4.3,
4.6, or 4.9.

I did manage to have parallelism detection kick in once though:

[...]
1087 - 2017-03-27 09:54:40.488734408+02:00: 
/cached_setup_font.sh.running created
1087 - 2017-03-27 09:54:40.509440184+02:00: 
/cached_setup_font.sh.running deleted
[reboot]
426 - 2017-03-27 09:57:39.157315082+02:00: 
/cached_setup_font.sh.running created
502 - 2017-03-27 09:57:40.195551438+02:00: 
/cached_setup_font.sh.running exists and contains [426 / 2017-03-27 
09:57:39.157315082+02:00], exiting
426 - 2017-03-27 09:57:40.709767317+02:00: 
/cached_setup_font.sh.running deleted
657 - 2017-03-27 09:57:42.245186312+02:00: 
/cached_setup_font.sh.running created
657 - 2017-03-27 09:57:42.268458964+02:00: 
/cached_setup_font.sh.running deleted

so at least we got this right, technically :-)

These boots were under slightly heavier load: two external
USB mass storage devices being online during the entire
reboot cycle, one of which acts as backup swap while the
other is a backup device being hit by another machine over
the network as soon as the problem machine reaches network
target.

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

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

On Sun, Mar 26, 2017 at 08:42:43PM +0300, Anton Zinoviev wrote:

>> I have done some more experimentation and it shows fairly
>> strange results.
> 
> Thanks a lot! :)

That is what I can contribute.

> > Sometimes cached_setup_font.sh does not seem to get run AT
> > ALL -- the log file simply does not exist after a clean boot.
> 
> Maybe this happened because cached_setup_font.sh was run while / was 
> still read-only?

Possibly. Suspecting that is why I chose / in the hope it'll
get mounted rw real early :-)

> > However, as witnessed by this log snippet from the most
> > recent boot, it does not ALWAYS run in parallel:
> 
> Let us clear one point: no matter whether it runs in parallel or not -- 
> the console is never configured properly?  Or sometimes it is?

It is NEVER configured properly anymore.

It used to always work until fairly recently (shortly before
I filed the bug) but now _never_ does, regardless of whether
I can find a log under /.

One thing I *haven't* tested yet is whether earlier kernel
would make a difference -- not that I would think but who
knows.

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

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

One more data point:

> I edited the file /etc/console-setup/cached_setup_font.sh
> to look like this:

...

> the idea being to prevent it from running in parallel.

...

> When the log file DOES exist it does indeed show
> cached_setup_font.sh to run in parallel "early" in the boot
> process and once more "later":

However, as witnessed by this log snippet from the most
recent boot, it does not ALWAYS run in parallel:

397 - 2017-03-26 15:53:08.218566865+02:00: 
/cached_setup_font.sh.running created
397 - 2017-03-26 15:53:09.054517233+02:00: 
/cached_setup_font.sh.running deleted
465 - 2017-03-26 15:53:09.569959665+02:00: 
/cached_setup_font.sh.running created
465 - 2017-03-26 15:53:09.656989307+02:00: 
/cached_setup_font.sh.running deleted
557 - 2017-03-26 15:53:09.701864078+02:00: 
/cached_setup_font.sh.running created
557 - 2017-03-26 15:53:09.743826537+02:00: 
/cached_setup_font.sh.running deleted

(it took much longer this time for the second process 465 to
be run)

The only thing I can think of maybe having been different
between this boot and other boots was: This time I let Debian
boot all the way into SDDM, then DID NOT switch to a console
right away but rather logged into KDE, and only switched to a
VT once KDE login was finished.

Probably doesn't help much, however. Thought I'd mention though.

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

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

I have done some more experimentation and it shows fairly
strange results.

I edited the file /etc/console-setup/cached_setup_font.sh
to look like this:

#!/bin/sh

# added
SEMAPHORE="/cached_setup_font.sh.running"
LOG="/console-cached_setup_font.sh-tracing.log"
TS=`date --rfc-3339=ns`
if test ! -f ${SEMAPHORE} ; then
> ${SEMAPHORE} ;
echo "$$ / $TS" > ${SEMAPHORE} ;
echo "$$ - $TS: ${SEMAPHORE} created" >> $LOG ;
else
VAL=`cat ${SEMAPHORE}` ;
echo "$$ - $TS: ${SEMAPHORE} exists and contains [$VAL], exiting" 
>> $LOG ;
exit 0 ;
fi
# ---

setfont '/etc/console-setup/Lat15-Terminus16.psf.gz'

if ls /dev/fb* >/dev/null 2>/dev/null; then
for i in /dev/vcs[0-9]*; do
{ :
setfont '/etc/console-setup/Lat15-Terminus16.psf.gz'
} < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs}
done
fi

mkdir -p /run/console-setup
> /run/console-setup/font-loaded
for i in /dev/vcs[0-9]*; do
{ :
printf '\033%%G'
} < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs}
done

# added
rm -f ${SEMAPHORE} >> $LOG
TS=`date --rfc-3339=ns`
echo "$$ - $TS: ${SEMAPHORE} deleted" >> $LOG
# ---

the idea being to prevent it from running in parallel.

Observations after many reboots with neither semaphore nor
log existing:

Sometimes cached_setup_font.sh does not seem to get run AT
ALL -- the log file simply does not exist after a clean boot.

When the log file DOES exist it does indeed show
cached_setup_font.sh to run in parallel "early" in the boot
process and once more "later":

421 - 2017-03-24 11:31:44.262310078+01:00: 
/cached_setup_font.sh.running created
423 - 2017-03-24 11:31:44.262785627+01:00: 
/cached_setup_font.sh.running created
421 - 2017-03-24 11:31:45.721488930+01:00: 
/cached_setup_font.sh.running deleted
423 - 2017-03-24 11:31:45.721489699+01:00: 
/cached_setup_font.sh.running deleted
659 - 2017-03-24 11:31:47.733106958+01:00: 
/cached_setup_font.sh.running created
659 - 2017-03-24 11:31:47.755347426+01:00: 
/cached_setup_font.sh.running deleted

Note how the two early runs even manage to race each other
within a few (4) microseconds:

421 - 2017-03-24 11:31:44.262*3*10078+01:00: 
/cached_setup_font.sh.running created
423 - 2017-03-24 11:31:44.262*7*85627+01:00: 
/cached_setup_font.sh.running created

which means that this code:

#!/bin/sh
# added
SEMAPHORE="/cached_setup_font.sh.running"
LOG="/console-cached_setup_font.sh-tracing.log"
TS=`date --rfc-3339=ns`
if test ! -f ${SEMAPHORE} ; then
> ${SEMAPHORE} ;
echo "$$ / $TS" > ${SEMAPHORE} ;

runs in less than 4 µs because it manages to race inbetween

if test ! -f ${SEMAPHORE} ; then
> ${SEMAPHORE} ;

(that's why I first create the semaphore before taking the
time to pipe data into it).

Here's what journalctl -b records for that time span:

Mär 24 11:31:43 hermes systemd[1]: Starting Load/Save RF Kill Switch 
Status...
Mär 24 11:31:44 hermes systemd[1]: Started Load/Save Screen Backlight 
Brightness of backlight:intel_backlight.
Mär 24 11:31:44 hermes systemd[1]: Started Load/Save Screen Backlight 
Brightness of backlight:acpi_video0.
Mär 24 11:31:44 hermes kernel: psmouse serio4: elantech: assuming 
hardware version 2 (with firmware version 0x040101)
Mär 24 11:31:44 hermes kernel: ath: phy0: Enable LNA combining
Mär 24 11:31:44 hermes kernel: ath: phy0: ASPM enabled: 0x42
Mär 24 11:31:44 hermes kernel: ath: EEPROM regdomain: 0x60
Mär 24 11:31:44 hermes kernel: ath: EEPROM indicates we should expect a 
direct regpair map
Mär 24 11:31:44 hermes kernel: ath: Country alpha2 being used: 00
Mär 24 11:31:44 hermes kernel: ath: Regpair used: 0x60
Mär 24 11:31:44 hermes kernel: psmouse serio4: elantech: Synaptics 
capabilities query result 0x7e, 0x13, 0x0d.
Mär 24 11:31:44 hermes kernel: psmouse serio4: elantech: Elan sample 
query result 19, 00, 00
Mär 24 11:31:44 hermes kernel: input: ETPS/2 Elantech Touchpad as 
/devices/platform/i8042/serio4/input/input15
Mär 24 11:31:44 hermes kernel: ieee80211 phy0: Selected rate control 
algorithm 'minstrel_ht'
Mär 24 11:31:44 hermes kernel: ieee80211 phy0: Atheros AR9285 Rev:2 
mem=0xf89b, irq=17
Mär 24 11:31:44 hermes kernel: iTCO_vendor_support: vendor-support=0
Mär 24 11:31:44 hermes kernel: iTCO_wdt: Intel TCO WatchDog Timer 
Driver v1.11
Mär 24 11:31:44 hermes kernel: iTCO_wdt: Found a ICH9M TCO device 
(Version=2, TCOBASE=0x0860)
Mär 24 11:31:44 hermes kernel: iTCO_wdt: initialized. heartbeat=30 

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

On Thu, Mar 23, 2017 at 03:04:37PM +0200, Anton Zinoviev wrote:

> Since systemd makes some configuration of the console, maybe the 
> following scenario might explain what we observe:

... lengthy analysis ...

> So, if this scenario is possible, a natural question is what can be done 
> in order to make sure the scripts of console-setup do not execute in 
> parallel with systemd while configuring the console.

This very much sounds like a possible cause for what I am
observing and should be the path to follow first.

Note that this problem has been observed previously (there's
old, resolved bugs around this) which had a similar solution.

A, perhaps fairly drastic, solution might be to delay
setupcon font setting until all getty's have been started ?

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

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

On Thu, Mar 23, 2017 at 11:07:14AM +0100, Sven Joachim wrote:

> >> > ls -l /etc/console-setup/
> >> 
> >>-rwxr-xr-x   1 root root   465 Mar 22 11:20 cached_setup_font.sh
> >>-rwxr-xr-x   1 root root   358 Mar 22 11:20 cached_setup_keyboard.sh
> >>-rwxr-xr-x   1 root root73 Mar 22 11:20 cached_setup_terminal.sh
> >
> > Hm, the times of these three are too recent. I can see two possibilities:
> >
> >   1. either the bug no longer exists in this system, in which case we 
> > have to find out what caused these files to be created, or
> >
> >   2. the bug still exists and each time the system boots, it recreates 
> > these three files.  In this case we have to find out the cause of this.
> 
> There might be a third possibility which seems to happen on one of my
> systems: the cached_setup_font.sh script does not work correctly when
> run during boot by udev.  Because this is what I am observing here, I
> even added some debug messages to it to see if it is run at all (as
> intended by /lib/udev/rules.d/90-console-setup.rules), and indeed it
> does run but the font still remains unchanged.

This very much hints at a dependency problems, does it not ? 
Does your system exhibiting this behaviour run systemd ?

> Manually running /etc/console-setup/cached_setup_font.sh (or
> setupcon -f, for that matter) works fine, so I'm a bit at a loss here.

I'll constrain my "fixup" script to "-f" now to see whether
that will consistently fix what I am seeing (IOW whether we
can constrain the problem to font setting, which is likely).

I have sometimes noted the following which seems to suggest
that some dependency may come up late:

Directly after boot, during which no VT switch occurred, I
will see the login manager for KDE. When I now switch to the
first console and then ALT-RIGHT through my other consoles up
until vt6 they don't have a getty running just yet (they show
up as empty black screens). The second round through all of
them exhibit the getty login prompt. This happens only very
rarely but it _does_ come up every so often. This fact does
seem to hint a gettys being spawned in a delayed fashion.

I have observed something else, but only ONCE so far:

After running setupcon to fix the font problem one console
(sitting at the login prompt) did not get the message - it
stayed in the old, wrong font. Re-running setupcon fixed that
console, too. Other consoles - which reset to the correct
font upon the first setupcon invocation - where either logged
in or sitting at the login prompt as well, so it's not
whether they were logged in or not.

Might there be a race between getty spawning and setupcon
running ?

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

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

On Wed, Mar 22, 2017 at 08:48:16PM +0200, Anton Zinoviev wrote:

> > 2017-03-22 13:05:13.364493514 +0100 /etc/console-setup/cached_setup_font.sh
> > 2017-03-22 13:05:13.364493514 +0100 
> > /etc/console-setup/cached_setup_keyboard.sh
> > 2017-03-22 13:05:13.364493514 +0100 
> > /etc/console-setup/cached_setup_terminal.sh
> > 2017-03-22 12:54:59.368053266 +0100 
> > /etc/console-setup/cached_UTF-8_del.kmap.gz
> > 2017-03-22 12:53:10.459239057 +0100 /etc/default/console-setup
> > 2017-03-07 09:26:01.171789164 +0100 /etc/default/keyboard
> 
> It seems something has changed /etc/default/console-setup. If this file 
> is changed, then boot scripts of console-setup will recreate the 
> cached_* files in /etc.
> 
> Do you know what has caused this file to be changed?

That was me, again, because I hoped that setting

# Change to "yes" and setupcon will explain what is being doing
VERBOSE_OUTPUT="yes"

from "no" to "yes" would generate helpful debugging output.
However, I haven't been able to find any :-/

> Something unrelated that might explain the bug is this: maybe this 
> system runs X

It does, yes.

> but doesn't have framebuffer on the console?

Oh, it does:

dmseg:
[   20.377384] fbcon: inteldrmfb (fb0) is primary device
...
[   21.054248] Console: switching to colour frame buffer device 170x48
[   21.084983] i915 :00:02.0: fb0: inteldrmfb frame buffer device


fbset -v -i

Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
(C) Copyright 1995-1999 by Geert Uytterhoeven

Opening frame buffer device `/dev/fb0'
Using current video mode from `/dev/fb0'

mode "1366x768"
geometry 1366 768 1366 768 32
timings 0 0 0 0 0 0 0
accel true
rgba 8/16,8/8,8/0,0/0
endmode

Getting further frame buffer information
Frame buffer device information:
Name: inteldrmfb
Address : 0xd0048000
Size: 4227072
Type: PACKED PIXELS
Visual  : TRUECOLOR
XPanStep: 1
YPanStep: 1
YWrapStep   : 0
LineLength  : 5504
Accelerator : No

> BTW, instead of `systemctl restart console-setup.service` you can use 
> the command `setupcon`.

OK, I will resort to that in order to minimize what is involved.

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

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

On Wed, Mar 22, 2017 at 04:49:27PM +0200, Anton Zinoviev wrote:

> Thanks. :) Well, can you report the state of the affairs before you run
> 
>   systemctl restart console-setup.service
> 
> ls --full-time /etc/default/{console-setup,keyboard} 
> /etc/console-setup/cached_*

Attached.

Full times directly after a reboot before manually restarting
console-setup.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-rwxr-xr-x 1 root root  465 2017-03-22 13:05:13.364493514 +0100 
/etc/console-setup/cached_setup_font.sh
-rwxr-xr-x 1 root root  358 2017-03-22 13:05:13.364493514 +0100 
/etc/console-setup/cached_setup_keyboard.sh
-rwxr-xr-x 1 root root   73 2017-03-22 13:05:13.364493514 +0100 
/etc/console-setup/cached_setup_terminal.sh
-rw-r--r-- 1 root root 4377 2017-03-22 12:54:59.368053266 +0100 
/etc/console-setup/cached_UTF-8_del.kmap.gz
-rw-r--r-- 1 root root 2061 2017-03-22 12:53:10.459239057 +0100 
/etc/default/console-setup
-rw-r--r-- 1 root root  587 2017-03-07 09:26:01.171789164 +0100 
/etc/default/keyboard

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

On Wed, Mar 22, 2017 at 03:02:28PM +0200, Anton Zinoviev wrote:

> > > ls -l /etc/console-setup/
> > 
> > -rwxr-xr-x   1 root root   465 Mar 22 11:20 cached_setup_font.sh
> > -rwxr-xr-x   1 root root   358 Mar 22 11:20 cached_setup_keyboard.sh
> > -rwxr-xr-x   1 root root73 Mar 22 11:20 cached_setup_terminal.sh
> 
> Hm, the times of these three are too recent. I can see two possibilities:
>
>   1. either the bug no longer exists in this system, in which case we 
> have to find out what caused these files to be created, or
> 
>   2. the bug still exists and each time the system boots, it recreates 
> these three files.  In this case we have to find out the cause of this.

The latter: currently, after each boot, I manually run

systemctl restart console-setup.service

which fixes the console problem for me until the next boot.
That's why those files are from today.

> Can you check if the times of these three files change each time the 
> system boots?

See above.

>  And what about the files 
> /etc/default/{keyboard,console-setup} -- do their times change too?

Likely because of the above, too.

> > (the line starting with ">" strikes me as odd - should it not
> >  be on the "mkdir -p" line ?)
> 
> This line creates an empty file /run/console-setup/font-loaded which is 

I eventually figured as much...

> used by /lib/udev/rules.d/90-console-setup.rules to make sure the script 
> /etc/console-setup/cached_setup_terminal.sh is not run before 
> /etc/console-setup/cached_setup_font.sh.

OK, got it.

> These look ok as well...

Feel free to ask for more information you may need.

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

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

On Wed, Mar 22, 2017 at 02:18:51PM +0300, Anton Zinoviev wrote:

> > is there anything I can do/provide to help get this resolved ?
> 
> Yes, thanks!  The output of the following commands:

Here you go:

> ls -l /etc/console-setup/

total 164
drwxr-xr-x   2 root root  4096 Mar  7 09:26 .
drwxr-xr-x 194 root root 12288 Mar 22 11:16 ..
-rw-r--r--   1 root root  2417 Mar  2  2011 Lat15-Fixed16.psf.gz
-rw-r--r--   1 root root  2328 Mar 11  2011 Lat15-Terminus16.psf.gz
-rw-r--r--   1 root root  2351 Nov 12  2010 Lat15-TerminusBold16.psf.gz
-rw-r--r--   1 root root  4086 Mar 11  2011 cached.kmap.gz
-rw-r--r--   1 root root  4377 Mar  7 09:26 cached_UTF-8_del.kmap.gz
-rwxr-xr-x   1 root root   465 Mar 22 11:20 cached_setup_font.sh
-rwxr-xr-x   1 root root   358 Mar 22 11:20 cached_setup_keyboard.sh
-rwxr-xr-x   1 root root73 Mar 22 11:20 cached_setup_terminal.sh
-rw-r--r--   1 root root34 Jan 11  2011 compose.ARMSCII-8.inc
-rw-r--r--   1 root root31 Jan 11  2011 compose.CP1251.inc
-rw-r--r--   1 root root31 Jan 11  2011 compose.CP1255.inc
-rw-r--r--   1 root root31 Jan 11  2011 compose.CP1256.inc
-rw-r--r--   1 root root41 Jan 11  2011 compose.GEORGIAN-ACADEMY.inc
-rw-r--r--   1 root root36 Jan 11  2011 compose.GEORGIAN-PS.inc
-rw-r--r--   1 root root32 Jan 11  2011 compose.IBM1133.inc
-rw-r--r--   1 root root35 Jan 11  2011 compose.ISIRI-3342.inc
-rw-r--r--   1 root root  3596 May 22  2016 compose.ISO-8859-1.inc
-rw-r--r--   1 root root36 Jan 11  2011 compose.ISO-8859-10.inc
-rw-r--r--   1 root root36 Jan 11  2011 compose.ISO-8859-11.inc
-rw-r--r--   1 root root  3737 May 22  2016 compose.ISO-8859-13.inc
-rw-r--r--   1 root root  3020 Mar  2  2016 compose.ISO-8859-14.inc
-rw-r--r--   1 root root  3552 May 22  2016 compose.ISO-8859-15.inc
-rw-r--r--   1 root root36 Jan 11  2011 compose.ISO-8859-16.inc
-rw-r--r--   1 root root  2893 May 22  2016 compose.ISO-8859-2.inc
-rw-r--r--   1 root root  3387 May 22  2016 compose.ISO-8859-3.inc
-rw-r--r--   1 root root  2805 May 22  2016 compose.ISO-8859-4.inc
-rw-r--r--   1 root root35 Jan 11  2011 compose.ISO-8859-5.inc
-rw-r--r--   1 root root35 Jan 11  2011 compose.ISO-8859-6.inc
-rw-r--r--   1 root root  1217 May 22  2016 compose.ISO-8859-7.inc
-rw-r--r--   1 root root35 Jan 11  2011 compose.ISO-8859-8.inc
-rw-r--r--   1 root root  3617 May 22  2016 compose.ISO-8859-9.inc
-rw-r--r--   1 root root31 Jan 11  2011 compose.KOI8-R.inc
-rw-r--r--   1 root root31 Jan 11  2011 compose.KOI8-U.inc
-rw-r--r--   1 root root32 Jan 11  2011 compose.TIS-620.inc
-rw-r--r--   1 root root31 Dec  5  2011 compose.VISCII.inc
-rw-r--r--   1 root root  1359 Dec  5  2011 remap.inc

> cat /etc/console-setup/cached_setup_font.sh

#!/bin/sh

setfont '/etc/console-setup/Lat15-Terminus16.psf.gz' 

if ls /dev/fb* >/dev/null 2>/dev/null; then
for i in /dev/vcs[0-9]*; do
{ :
setfont '/etc/console-setup/Lat15-Terminus16.psf.gz' 
} < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs}
done
fi

mkdir -p /run/console-setup
> /run/console-setup/font-loaded
for i in /dev/vcs[0-9]*; do
{ :
printf '\033%%G' 
} < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs}
done


(the line starting with ">" strikes me as odd - should it not
 be on the "mkdir -p" line ?)

> cat /etc/console-setup/cached_setup_terminal.sh

#!/bin/sh

{ :
printf '\033%%G' 
} < /dev/tty${1#vcs} > /dev/tty${1#vcs}

> cat /etc/default/console-setup

# Change to "yes" and setupcon will explain what is being doing
VERBOSE_OUTPUT="no"

# Setup these consoles.  Most people do not need to change this.
ACTIVE_CONSOLES="/dev/tty[1-6]"

# Put here your encoding.  Valid charmaps are: UTF-8 ARMSCII-8 CP1251
# CP1255 CP1256 GEORGIAN-ACADEMY GEORGIAN-PS IBM1133 ISIRI-3342
# ISO-8859-1 ISO-8859-2 ISO-8859-3 ISO-8859-4 ISO-8859-5 ISO-8859-6
# ISO-8859-7 ISO-8859-8 ISO-8859-9 ISO-8859-10 ISO-8859-11 ISO-8859-13
# ISO-8859-14 ISO-8859-15 ISO-8859-16 KOI8-R KOI8-U TIS-620 VISCII
CHARMAP="UTF-8"

# The codeset determines which symbols are supported by the font.
# Valid codesets are: Arabic Armenian CyrAsia CyrKoi CyrSlav Ethiopian
# Georgian Greek Hebrew Lao Lat15 Lat2 Lat38 Lat7 Thai Uni1 Uni2 Uni3
# Vietnamese.  Read README.fonts for explanation.
CODESET="Lat15"

# Valid font faces are: VGA (sizes 8, 14 and 16), Terminus (sizes
# 12x6, 14, 16, 20x10, 

Bug#857132: console-setup: additional info needed ?

[Karsten Hilbert]

Package: console-setup
Version: 1.163
Followup-For: Bug #857132

Hi,

is there anything I can do/provide to help get this resolved ?

Thanks,
Karsten

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

Kernel: Linux 4.10.0-trunk-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 console-setup depends on:
ii  console-setup-linux 1.163
ii  debconf 1.5.60
ii  keyboard-configuration  1.163
ii  xkb-data2.19-1

console-setup recommends no packages.

Versions of packages console-setup suggests:
ii  locales   2.24-9
ii  lsb-base  9.20161125

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.60
ii  liblocale-gettext-perl  1.07-3+b1

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.47
ii  initscripts 2.88dsf-59.9
ii  kbd 2.0.3-2+b1
ii  keyboard-configuration  1.163

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.0.3-2+b1
ii  systemd   232-19

-- debconf information excluded

Bug#857132: console-setup (again) stopped to apply font at startup

[Karsten Hilbert]

On Wed, Mar 08, 2017 at 02:21:59PM +0200, Anton Zinoviev wrote:

>> console-setup just stopped to apply font settings during startup.
> 
> Does this system has some read-only file systems?

Not that I am aware of, no.

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

Bug#857132: console-setup (again) stopped to apply font at startup

[Karsten Hilbert]

Package: console-setup
Version: 1.163
Severity: important

Hi,

console-setup just stopped to apply font settings during startup. This
happened before and was fixed about a year ago:

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

Maybe not the same reason but the faulty behaviour is back...

Manually running

systemctl restart console-setup.service

fixes the problem until the next reboot.

Thanks for looking into the issue,
Karsten


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

Kernel: Linux 4.10.0-trunk-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 console-setup depends on:
ii  console-setup-linux 1.163
ii  debconf 1.5.60
ii  keyboard-configuration  1.163
ii  xkb-data2.19-1

console-setup recommends no packages.

Versions of packages console-setup suggests:
ii  locales   2.24-9
ii  lsb-base  9.20161125

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.60
ii  liblocale-gettext-perl  1.07-3+b1

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.47
ii  initscripts 2.88dsf-59.9
ii  kbd 2.0.3-2+b1
ii  keyboard-configuration  1.163

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.0.3-2+b1
ii  systemd   232-18

-- debconf information:
  console-setup/fontsize-text47: 8x16
* console-setup/charmap47: UTF-8
  debian-installer/console-setup-udeb/title:
* keyboard-configuration/model: Generische PC-Tastatur mit 105 Tasten (Intl)
  keyboard-configuration/unsupported_config_options: true
  keyboard-configuration/layout:
  console-setup/codesetcode: Lat15
  console-setup/guess_font:
  console-setup/framebuffer_only:
* console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic 
languages
  console-setup/use_system_font:
  keyboard-configuration/toggle: No toggling
* console-setup/fontsize-fb47: 8x16
  keyboard-configuration/modelcode: pc105
  console-setup/store_defaults_in_debconf_db: true
  keyboard-configuration/layoutcode: de
* keyboard-configuration/ctrl_alt_bksp: false
  console-setup/fontsize: 8x16
  keyboard-configuration/store_defaults_in_debconf_db: true
  keyboard-configuration/unsupported_layout: true
* keyboard-configuration/variant: Deutsch - Deutsch (ohne Akzenttasten)
  keyboard-configuration/unsupported_config_layout: true
  keyboard-configuration/optionscode:
  keyboard-configuration/other:
* keyboard-configuration/altgr: The default for the keyboard layout
* console-setup/fontface47: Terminus
  keyboard-configuration/variantcode: nodeadkeys
* keyboard-configuration/compose: No compose key
  keyboard-configuration/xkb-keymap: de(nodeadkeys)
  keyboard-configuration/unsupported_options: true
  keyboard-configuration/switch: No temporary switch

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#835334: tex-common: failed on other fonts today

[Karsten Hilbert]

Package: tex-common
Version: 6.06
Followup-For: Bug #835334

I ran

apt update
apt uprade

today which included a TeX update including several language packs.

tex-common failed with the attached messages. Neither of

apt-get dist-uprade nor
apt-get -f install

fixes the problem for me.

mktexlsr _is_ run, as the log shows, so that hint from the updmap file
does not help.

Thanks,
Karsten

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

Kernel: Linux 4.7.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 tex-common depends on:
ii  dpkg  1.18.18
ii  ucf   3.0036

tex-common recommends no packages.

Versions of packages tex-common suggests:
ii  debhelper  10.2.3

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.60
ii  libpaper-utils 1.1.24+nmu5
ii  texlive-binaries   2016.20160513.41080.dfsg-1
ii  ucf3.0036
ii  xdg-utils  1.1.1-1

Versions of packages texlive-base recommends:
ii  lmodern  2.004.5-3

Versions of packages texlive-base suggests:
ii  ghostscript [postscript-viewer]  9.20~dfsg-1
ii  okular [postscript-viewer]   4:16.08.2-1
pn  perl-tk  
pn  xpdf-reader | pdf-viewer 

Versions of packages texlive-binaries depends on:
ii  dpkg  1.18.18
ii  install-info  6.3.0.dfsg.1-1+b1
ii  libc6 2.24-8
ii  libcairo2 1.14.8-1
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.3.0-5
ii  libgmp10  2:6.1.2+dfsg-1
ii  libgraphite2-31.3.9-3
ii  libgs99.20~dfsg-1
ii  libharfbuzz-icu0  1.2.7-1+b1
ii  libharfbuzz0b 1.2.7-1+b1
ii  libice6   2:1.0.9-1+b1
ii  libicu57  57.1-5
ii  libkpathsea6  2016.20160513.41080.dfsg-1
ii  libmpfr4  3.1.5-1
ii  libpaper1 1.1.24+nmu5
ii  libpixman-1-0 0.34.0-1
ii  libpng16-16   1.6.28-1
ii  libpoppler64  0.48.0-2
ii  libpotrace0   1.13-3
ii  libptexenc1   2016.20160513.41080.dfsg-1
ii  libsm62:1.2.2-1+b1
ii  libstdc++66.3.0-5
ii  libsynctex1   2016.20160513.41080.dfsg-1
ii  libtexlua52   2016.20160513.41080.dfsg-1
ii  libtexluajit2 2016.20160513.41080.dfsg-1
ii  libx11-6  2:1.6.4-2
ii  libxaw7   2:1.0.13-1
ii  libxext6  2:1.3.3-1
ii  libxi62:1.7.8-2
ii  libxmu6   2:1.1.2-2
ii  libxpm4   1:3.5.12-1
ii  libxt61:1.1.5-1
ii  libzzip-0-13  0.13.62-3
ii  perl  5.24.1-1
ii  t1utils   1.39-2
ii  zlib1g1:1.2.8.dfsg-4

Versions of packages texlive-binaries recommends:
ii  python2.7.13-1
ii  ruby  1:2.3.3
ii  texlive-base  2016.20161130-1
ii  tk [wish] 8.6.0+9

-- debconf information:
  texlive-base/texconfig_ignorant:
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
Skript gestartet auf Do 02 Feb 2017 09:20:41 CET
root@hermes:~# apt-get -f install

Paketlisten werden gelesen... 0%

Paketlisten werden gelesen... 100%

Paketlisten werden gelesen... Fertig


Abhängigkeitsbaum wird aufgebaut 0%

Abhängigkeitsbaum wird aufgebaut 0%

Abhängigkeitsbaum wird aufgebaut 50%

Abhängigkeitsbaum wird aufgebaut 50%

Abhängigkeitsbaum wird aufgebaut.   


Statusinformationen werden eingelesen 0%

Statusinformationen werden eingelesen 0%

Statusinformationen werden eingelesen Fertig

Die folgenden Pakete wurden automatisch installiert und werden nicht mehr 
benötigt:
  acpica-tools appstream-index apt-xapian-index aptitude-common attr 
debconf-kde-data dia-libs easy-rsa firebird2.5-common firebird2.5-common-doc
  firebird2.5-server-common firebird3.0-common firebird3.0-common-doc 
firefox-esr-l10n-de firefox-esr-l10n-ja fonts-inconsolata fonts-roboto 
gdebi-core
  gstreamer0.10-gconf gstreamer0.10-nice gstreamer0.10-x hardening-includes 
imagemagick-common kaccounts-providers kcalc kdeconnect kdepim-runtime 
kdeplasma-addons-data
  kross ktimer kwin-style-qtcurve libaccounts-glib0 libaccounts-qt5-1 libadns1 
libakonadiprotocolinternals1 libalgorithm-c3-perl libamd2.4.1 libappstream-glib7
  libappstream3 libappstreamqt1 libapt-inst1.5 libapt-pkg4.12 
libarchive-extract-perl libarmadillo6 libasn1-8-heimdal libatk-wrapper-java 
libatk-wrapper-java-jni
  libavdevice-ffmpeg56 libavfilter-ffmpeg5 libavformat-ffmpeg56 libbaloocore4 
libbaloofiles4 libbaloopim4 libbalooqueryparser4 libbalooxapian4 
libbasicusageenvironment0
  libbind9-90 libboost-atomic1.61.0 libboost-chrono1.61.0 
libboost-context1.61.0 libboost-coroutine1.61.0 libboost-date-time1.61.0 
libboost-filesystem1.61.0
  

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Fri, Dec 30, 2016 at 10:57:56AM +0100, Sébastien Jodogne wrote:

> Sorry, my mistake: Preventing Orthanc from starting after an upgrade of the
> database schema was on my TODO list... it is not implemented yet. I have
> just added an issue on the upstream bug tracker to avoid forgetting it:
> https://bitbucket.org/sjodogne/orthanc/issues/29
> 
> This feature will be part of forthcoming 1.2.1 release.

Thanks a lot for confirming. I will test when 1.2.1 is out
and provide a script users can run updating the database
schema if needed.

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

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Thu, Dec 29, 2016 at 11:02:25AM +0100, Sébastien Jodogne wrote:

> > may I ask for confirmation of the following behaviour:
> > 
> > If Orthanc is manually started for a DB upgrade
> > 
> > (say, on Debian:)
> > /usr/sbin/Orthanc --upgrade --trace /etc/orthanc/
> > 
> > BUT the database is already at the required version THEN
> > Orthanc will not run the upgrade and fall back to starting
> > up as if --upgrade was not specified on the command line.
> 
> No: If the "--upgrade" command-line option is provided, the Orthanc server
> will never start. If no upgrade is required, this is a void operation that
> returns immediately.

I would have thought so. However, why does this script:

#-------------
#!/bin/bash

# GPLv2 or later, Karsten Hilbert

set -x

LOGDIR=/var/log/orthanc
LOGFILE=${LOGDIR}/upgrade.log
ARGS="--upgrade --trace /etc/orthanc/"
ORTHANC_BINARY=`which Orthanc`


echo "Stopping Orthanc server..."
echo "#---" &> ${LOGFILE}
systemctl stop orthanc.service &>> ${LOGFILE}
RESULT=$?
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
sleep 1s
if [ ${RESULT} -ne 0 ] ; then
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Cannot stop Orthanc, please inspect the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo "Attempting database upgrade..."
echo "#---" &>> ${LOGFILE}
echo "Running <${ORTHANC_BINARY} ${ARGS}>" >> ${LOGFILE}
sudo -u orthanc ${ORTHANC_BINARY} ${ARGS} &>> ${LOGFILE}
RESULT=$?
if [ ${RESULT} -ne 0 ] ; then
cat ${ORTHANC_LOG} &>> ${LOGFILE}
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Upgrade failed, please check the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo "Restarting Orthanc server..."
sleep 1s
echo "#---" &>> ${LOGFILE}
systemctl start orthanc.service &>> ${LOGFILE}
RESULT=$?
if [ ${RESULT} -ne 0 ] ; then
echo "#---" &>> ${LOGFILE}
systemctl status orthanc.service &>> ${LOGFILE}
echo "Cannot restart Orthanc, please check the log: ${LOGFILE}"
read -p "Press  to inspect the log" TMP
less ${LOGFILE}
exit ${RESULT}
fi


echo ""
echo "Seems successful..."
echo "Log: ${LOGFILE}"
echo ""
systemctl status orthanc.service
#-

stop at "Attempting database upgrade" until I hit
CTRL-C and show this output:

#-
Skript gestartet auf Do 29 Dez 2016 13:28:46 CET
root@hermes:~/orthanc# ./orthanc-upgrade_db 
+ LOGDIR=/var/log/orthanc
+ LOGFILE=/var/log/orthanc/upgrade.log
+ ARGS='--upgrade --trace /etc/orthanc/'
++ which Orthanc
+ ORTHANC_BINARY=/usr/sbin/Orthanc
+ echo 'Stopping Orthanc server...'
Stopping Orthanc server...
+ echo '#---'
+ systemctl stop orthanc.service
+ RESULT=0
+ echo '#---'
+ systemctl status orthanc.service
+ sleep 1s
+ '[' 0 -ne 0 ']'
+ echo 'Attempting database upgrade...'
Attempting database upgrade...
+ echo '#---'
+ echo 'Running '
+ sudo -u orthanc /usr/sbin/Orthanc --upgrade --trace /etc/orthanc/
^C+ RESULT=0
+ '[' 0 -ne 0 ']'
+ echo 'Restarting Orthanc server...'
Restarting Orthanc server...
+ sleep 1s
+ echo '#---'
+ systemctl start orthanc.service
+ RESULT=0
+ '[' 0 -ne 0 ']'
+ echo ''

+ echo 'Seems successful...'
Seems successful...
+ echo 'Log: /var/log/orthanc/upgrade.log'
Log: /var/log/orthanc/upgrade.log
+ echo ''

+ systemctl status orthanc.service

● orthanc.service - LSB: Orthanc init scri

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

Hello Sebastian,

may I ask for confirmation of the following behaviour:

If Orthanc is manually started for a DB upgrade

(say, on Debian:)
/usr/sbin/Orthanc --upgrade --trace /etc/orthanc/

BUT the database is already at the required version THEN
Orthanc will not run the upgrade and fall back to starting
up as if --upgrade was not specified on the command line.

The Orthanc book makes me think that when an upgrade is
actually run Orthanc will automatically stop after upgrading.

If you can confirm that Orthanc does NOT stop if no upgrade
is required even if --upgrade is specified then I would like
to ask for a change of this behaviour. Typically, one would
expect Orthanc to end up in the same state (DB upgraded and
server stopped) after an --upgrade run regardless of whether
an actual upgrade was performed.

https://en.wikipedia.org/wiki/Principle_of_least_astonishment

That would make the process predictable and thereby
scriptable. The exit code would make it possible to
differentiate between success and failure where
nothing-to-do-because-up-to-date counts as success.

Any chance this can get implemented ?

(Should be pretty much a one-liner.)

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

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Wed, Dec 14, 2016 at 10:43:07AM +0100, Sebastien Jodogne wrote:

> > Well, once Orthanc 1.2 shows up in my sources.lst I will test
> > the suggested script and report back. Since I don't assume
> > Orthanc 1.1 -> 1.2 to actually need a database upgrade (?) I
> > expect the script to gracefully do nothing.
> 
> Indeed, an upgrade of the Orthanc database is only necessary if the version
> of the DB changes.

I know.

> The last modification of the DB schema was introduced in Orthanc 0.9.5
> (released on December 2nd, 2015).

I recalled as much which is why I inferred that, currently,
no upgrade is necessary.

> the database schema is now considered as stable

I sure wish that to be so but there's always Famous Last Words.

> Furthermore, I personally feel that the upgrade process should imply a
> manual operation from the user.

Sure.

> As a consequence, I am not convinced that providing an automated script is 
> necessary.

No one suggested an _automated_ script.

I suggest to provide a script which calls "Orthanc -upgrade"
in the Debian-specific technically proper way _when run by
the user_. Which is what the suggested script does.

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

Bug#829380: Orthanc 1.2.0

[Karsten Hilbert]

On Wed, Dec 14, 2016 at 06:49:20AM +0100, Sébastien Jodogne wrote:

> This issue is very low priority wrt. my TODO list for the upstream project.

Understandable.

> Anyone is obviously welcome to help me and contribute by packaging this
> script into the orthanc Debian package.

...

> Le 14 déc. 2016 06:42, "Andreas Tille"  a écrit :

> Do you plan to provide any upgrade script as it was asked for in
> 
>https://bugs.debian.org/829380

Actually, that bug report did not simply _ask_ for a script
but also provided a concrete suggestion which I hoped would
be looked at, obvious errors pointed out so I can fix them,
and then included in one of the next versions.

Well, once Orthanc 1.2 shows up in my sources.lst I will test
the suggested script and report back. Since I don't assume
Orthanc 1.1 -> 1.2 to actually need a database upgrade (?) I
expect the script to gracefully do nothing. If that's so I'll
confirm this here and hope to get the script included in the
debian git tree.

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

Bug#813638: closed by Gert Wollny <gw.foss...@gmail.com> (Bug#813638: fixed in aeskulap 0.2.2b1+git20161206-1)

[Karsten Hilbert]

On Fri, Dec 09, 2016 at 10:36:14AM +, Debian Bug Tracking System wrote:

> #813638: wishlist: add --dicomdir commandline option

> Source: aeskulap
> Source-Version: 0.2.2b1+git20161206-1
> 
> We believe that the bug you reported is fixed in the latest version of
> aeskulap, which is due to be installed in the Debian FTP archive.

Works for me, thanks !

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

Bug#838294: dvdisaster: please consider packaging

[Karsten Hilbert]

Package: dvdisaster
Version: 0.79.3-1
Followup-For: Bug #838294

Dear maintainers,

it would be really nice if you would consider packaging the newer version
which is much faster on modern machines.

Thanks for your time,
Karsten


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

Kernel: Linux 4.7.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 dvdisaster depends on:
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-5
ii  libcairo2   1.14.6-1.1
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libglib2.0-02.50.2-1
ii  libgtk2.0-0 2.24.31-1
ii  libpango1.0-0   1.40.3-3
ii  xdg-utils   1.1.1-1

Versions of packages dvdisaster recommends:
ii  dvdisaster-doc  0.72.4-1

dvdisaster suggests no packages.

-- no debconf information

Bug#823141: RFP: timeline -- An application to show events on a timeline

[Karsten Hilbert]

Hi,

I have filed an RFP

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

(I would rather name those WFP - Wish For Packaging, but, oh
well) for a Python based timeline application

http://thetimelineproj.sourceforge.net

Contrary to the report it would need to be named, say,

thetimelineproj
py-timeline
pytimeline
timelinenavigator

or some such because Mattia Rizzolo pointed out that
"timeline" already exists

https://tracker.debian.org/pkg/timeline

as a source package (not that I think that that's a good fit
for a generic mozilla extension source package but first
come first serve I guess ... :)

Upstream agrees that "timeline" is too generic a name.

https://sourceforge.net/p/thetimelineproj/mailman/message/35055472/

I wondered whether someone in "pkg-python-apps" would have
the resources and interest to maintain a package. Matthia
suggested I contact this list to find out.

Note that I don't _expect_ people to devote time and energy
just because I think that'd be useful but unless I ask I
can't know :-)

Upstream's installation instructions are here:

http://thetimelineproj.sourceforge.net/installing.html

Fedora does have a package (Ubuntu does not):

https://admin.fedoraproject.org/pkgdb/package/rpms/timeline/

There's an unmet dependancy on humblewx

https://github.com/thetimelineproj/humblewx

which is available from PyPI, however:

https://pypi.python.org/pypi/humblewx

Metadata-Version: 1.0
Name: humblewx
Version: 0.2.1
Summary: Library that simplifies creating user interfaces with wxPython.
Home-page: https://github.com/thetimelineproj/humblewx
Author: Rickard Lindberg
Author-email: ricl...@gmail.com
License: GPLv3
Location: /usr/local/lib/python2.7/dist-packages
Requires: 
Classifiers:

Anything else I can provide ?

Thanks for considering,
Karsten (on behalf of GNUmed)
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Bug#823141: RFP: timeline -- An application to show events on a timeline

[Karsten Hilbert]

On Sat, Jul 23, 2016 at 10:48:42PM +, Mattia Rizzolo wrote:

> > If you mind reading but a few more lines in this wishlist
> > item you'll notice that I already acknowledge this problem
> > and even sought upstreams help/opinion on it.
> 
> umh, not really.  I read it fully before and I actually read this on the
> second post:
> 
> > In particular, "timeline" is way too generic a package name
> > (although there is no collision ATM).
> ↑
> 
> both upstream and you both acknowledged it was "a too generic name", but
> nothing about collisions and actual needs of renaming.

Sorry, if seen this way you are right.

I probably did

apt-cache show timeline
apt-cache search timeline

and did not find a package named "timeline".

bti - command line Twitter client
flasm - assembler and disassembler for Flash (SWF) bytecode
flowblade - non-linear video editor
harvid - HTTP Ardour Video Server
identicurse - simple Identi.ca client with a curses-based UI
libeventviews4 - event viewing library
mac-robber - collects data about allocated files in mounted filesystems
python-releases - Sphinx extension for changelog manipulation (Python 2)
python3-releases - Sphinx extension for changelog manipulation (Python 
3)
libreact-ocaml - functional reactive programming in OCaml (plugins)
libreact-ocaml-dev - functional reactive programming in OCaml
libjs-simile-timeline - JavaScript library for web-based interactive 
timelines
snapper - Linux filesystem snapshot management tool
libstapler-adjunct-timeline-java - Timeline visualisation library for 
use with stapler
libstapler-adjunct-timeline-java-doc - Documentation for Stapler 
Timeline
statcvs - CVS Repository statistic analysis tool, written in Java
threadscope - graphical thread profiler for Haskell programs
twittering-mode - Twitter client for Emacs
abi-monitor - monitor ABI of shared libraries
debian-timeline - Web-based timeline of the Debian Project
likwid - toolsuite for performance oriented programmers
plaso - super timeline all the things
python-releases-doc - Sphinx extension for changelog manipulation 
documentation
smuxi-engine - Engine libraries for Smuxi (IRC, Twitter, XMPP, 
Campfire, JabbR)
texlive-latex-extra - TeX Live: LaTeX additional packages
xul-ext-timeline - adds a timeline above the Thunderbird status bar
twitterwatch - Simple Twitter bot detecting if no tweet was posted 
recently on a timeline
python-twython - Pure Python wrapper for the Twitter API
python3-twython - Pure Python3 wrapper for the Twitter API
hotot - lightweight microblogging client - metapackage
hotot-common - lightweight microblogging client - common files
hotot-gtk - lightweight microblogging client - GTK+ wrapper
hotot-qt - lightweight microblogging client - QT wrapper

I suggest naming the package "thetimelineproj".

I will also contact "pkg-python-apps" via
"debian-pyt...@lists.debian.org" as you suggested.

Thank you for your insight.

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

Bug#823141: RFP: timeline -- An application to show events on a timeline

[Karsten Hilbert]

On Sat, Jul 23, 2016 at 07:28:57PM +, Mattia Rizzolo wrote:

> On Sun, May 01, 2016 at 01:59:08PM +0200, ncq wrote:
> > Package: wnpp
> > Severity: wishlist
> > 
> > * Package name: timeline
> 
> hold on, there is already a package with that name in debian, so whoever
> packages this have to pick another.

If you mind reading but a few more lines in this wishlist
item you'll notice that I already acknowledge this problem
and even sought upstreams help/opinion on it.

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

Bug#829383: orthanc-postgresql: please provide backup script

[Karsten Hilbert]

Package: orthanc-postgresql
Version: 2.0-2
Severity: wishlist
Tags: patch upstream

Please consider adjusting the attached backup script to be installed in
/usr/sbin/ and used by, say, cron.

It needs a

Depends: xz-utils, tar, postgresql-client-common

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
#!/bin/sh

BACKUP_DIR="/root/backup/orthanc/"

mkdir -p ${BACKUP_DIR}

TS=`date +%Y-%m-%d-%H-%M-%S`
sudo -u orthanc pg_dump --verbose --blobs --clean --if-exists --create --format=tar --file=/tmp/orthanc-backup.tar --dbname=orthanc_db
xz /tmp/orthanc-backup.tar
mv /tmp/orthanc-backup.tar.xz ${BACKUP_DIR}/orthanc-backup-${TS}.tar.xz

Bug#829380: orthanc: example upgrade script

[Karsten Hilbert]

Package: orthanc
Version: 1.1.0+dfsg-1
Followup-For: Bug #829380

Attached find an example which needs more testing.

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 depends on:
ii  adduser3.115
ii  dcmtk  3.6.1~20150924-5+b1
ii  libboost-filesystem1.58.0  1.58.0+dfsg-5.1
ii  libboost-locale1.58.0  1.58.0+dfsg-5.1
ii  libboost-regex1.58.0   1.58.0+dfsg-5.1
ii  libboost-system1.58.0  1.58.0+dfsg-5.1
ii  libboost-thread1.58.0  1.58.0+dfsg-5.1
ii  libc6  2.22-11
ii  libcurl3   7.47.0-1
ii  libdcmtk5  3.6.1~20150924-5+b1
ii  libgcc11:6.1.1-7
ii  libjpeg62-turbo1:1.5.0-1
ii  libjsoncpp11.7.2-1
ii  liblua5.1-05.1.5-8
ii  libpng16-161.6.23-1
ii  libpugixml1v5  1.7-2
ii  libsqlite3-0   3.13.0-1
ii  libssl1.0.21.0.2h-1
ii  libstdc++6 6.1.1-7
ii  libuuid1   2.28-5
ii  zlib1g 1:1.2.8.dfsg-2+b1

orthanc recommends no packages.

orthanc suggests no packages.

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

-- no debconf information
#!/bin/sh

LOGDIR=/var/log/orthanc
LOGFILE=${LOGDIR}/upgrade.log
ARGS="--upgrade --trace --logfile=${LOGFILE} /etc/orthanc/"

echo "Stopping Orthanc server..."
sleep 1s
systemctl stop orthanc.service
sleep 2s

echo "Attempting database upgrade..."
/usr/sbin/Orthanc ${ARGS}
RESULT=$?

if [ ${RESULT} -ne 0 ] ; then
	echo "Upgrade failed, please check the log: ${LOGDIR}"
	read -p "Press  to continue and see the log" TMP
	less ${LOGFILE}
	exit 1
fi

echo "Restarting Orthanc server..."
sleep 1s
systemctl start orthanc.service
systemctl status orthanc.service

echo ""
echo "Log: ${LOGFILE}"

Bug#829380: orthanc: please provide orthanc_upgrade script

[Karsten Hilbert]

Package: orthanc
Version: 1.1.0+dfsg-1
Severity: wishlist

Dear maintainer,

please provide a

/usr/sbin/orthanc_upgrade

script running something along these lines:

systemctl stop orthanc.service
/usr/sbin/Orthanc --upgrade --trace 
--logfile=/var/log/orthanc/upgrade.log /etc/orthanc/
RESULT=$?
if [ $RESULT -ne 0 ] ; then
echo "error upgrading"
read -e
less /var/log/orthanc/upgrade.log
exit $RESULT
fi
systemctl start orthanc.service

as discussed here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818757#70

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 depends on:
ii  adduser3.115
ii  dcmtk  3.6.1~20150924-5+b1
ii  libboost-filesystem1.58.0  1.58.0+dfsg-5.1
ii  libboost-locale1.58.0  1.58.0+dfsg-5.1
ii  libboost-regex1.58.0   1.58.0+dfsg-5.1
ii  libboost-system1.58.0  1.58.0+dfsg-5.1
ii  libboost-thread1.58.0  1.58.0+dfsg-5.1
ii  libc6  2.22-11
ii  libcurl3   7.47.0-1
ii  libdcmtk5  3.6.1~20150924-5+b1
ii  libgcc11:6.1.1-7
ii  libjpeg62-turbo1:1.5.0-1
ii  libjsoncpp11.7.2-1
ii  liblua5.1-05.1.5-8
ii  libpng16-161.6.23-1
ii  libpugixml1v5  1.7-2
ii  libsqlite3-0   3.13.0-1
ii  libssl1.0.21.0.2h-1
ii  libstdc++6 6.1.1-7
ii  libuuid1   2.28-5
ii  zlib1g 1:1.2.8.dfsg-2+b1

orthanc recommends no packages.

orthanc suggests no packages.

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

-- no debconf information

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: Bug#818757: orthanc-postgresql: does not start

[Karsten Hilbert]

On Wed, Jun 29, 2016 at 05:13:25PM +0200, Sebastien Jodogne wrote:

> Oh... thanks for reporting this issue. It is now fixed:
> https://anonscm.debian.org/viewvc/debian-med?view=revision=22265
> 
> Sébastien-
> 
> 
> > That's usually created automatically since a certain point of time if
> > you build the package.  I intended to verify this for
> > orthanc-postgresql_2.0 but get a build error. :-(
> > 
> > -- Could NOT find PostgreSQL (missing:  PostgreSQL_TYPE_INCLUDE_DIR) (found 
> > version "9.5.3")

There seems to be a similar bug reported in January:

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

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 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#823139: closed by Sebastien Jodogne <s.jodo...@gmail.com> (Bug#823139: fixed in orthanc 1.1.0+dfsg-1)

[Karsten Hilbert]

On Mon, Jun 27, 2016 at 10:30:08PM +, Debian Bug Tracking System wrote:

> please compile and provide
>   Samples/Tools/RecoverCompressedFile.cpp
> as
>   /usr/sbin/orthanc-recover_compressed_file
...
> If /usr/sbin/orthanc-recover_compressed_file were available I
> could provide helper scripts upgrading the database.

For the time being attached find a shell script which makes
using /usr/bin/OrthancCompressedFile a lot more convenient
(given exiftool and dicom3tools are installed).

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

DCMFILE="$1"
LOG=${DCMFILE}.log

OrthancRecoverCompressedFile ${DCMFILE} ${DCMFILE}.uncompressed &> ${LOG}
RESULT=$?

if [ $RESULT -ne 0 ] ; then
echo "cannot uncompress ${DCMFILE}"
echo "--- file" &>> ${LOG}
file ${DCMFILE} &>> ${LOG}
echo "--- dciodvfy" &>> ${LOG}
dciodvfy -filename ${DCMFILE} &>> ${LOG}
echo "--- dcentvfy" &>> ${LOG}
dcentvfy -veryverbose ${DCMFILE} &>> ${LOG}
echo "--- exiftool" &>> ${LOG}
exiftool ${DCMFILE} &>> ${LOG}
echo 
"--"
less ${LOG}
fi

exit ${RESULT}

Bug#828949: orthanc-webviewer: "better" suggestion for cache location

[Karsten Hilbert]

Package: orthanc-webviewer
Version: 2.1-1+b1
Severity: minor

Hi,

the (commented out) default provided for the cache path is

"CachePath" : "/tmp/WebViewerCache",

Howevever, "WebViewerCache" is quite generic and might clash with other
packages. I suggest setting the (commented out) default to

"CachePath" : "/tmp/OrthancWebViewerCache",

(or some such) instead.

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-webviewer depends on:
ii  libboost-filesystem1.58.0  1.58.0+dfsg-5+b1
ii  libboost-locale1.58.0  1.58.0+dfsg-5+b1
ii  libboost-regex1.58.0   1.58.0+dfsg-5+b1
ii  libboost-system1.58.0  1.58.0+dfsg-5+b1
ii  libboost-thread1.58.0  1.58.0+dfsg-5+b1
ii  libc6  2.22-11
ii  libgcc11:6.1.1-7
ii  libgdcm2.6 2.6.3-6
ii  libjsoncpp11.7.2-1
ii  libsqlite3-0   3.13.0-1
ii  libstdc++6 6.1.1-7
ii  libuuid1   2.28-5
ii  orthanc1.1.0+dfsg-1

orthanc-webviewer recommends no packages.

orthanc-webviewer suggests no packages.

-- Configuration Files:
/etc/orthanc/webviewer.json changed:
{
  /**
   * The following options control the configuration of the Orthanc
   * Web Viewer plugin.
   **/
  "WebViewer" : {
  /**
   * The location of the cache of the Web viewer. By default, the
   * cache is located inside the storage directory of Orthanc.
   **/
  // "CachePath" : "/tmp/WebViewerCache",
  "CachePath" : "/tmp/OrthancWebViewerCache",
  
  /**
   * The maximum size for the cached images, in megabytes. By
   * default, a cache of 100 MB is used.
   **/
  // "CacheSize" : 10,
  /**
   * The number of threads that are used by the plugin to decode
   * the DICOM images.
   **/
  // "Threads" : 4
  "Threads" : 2
  }
}


-- no debconf information

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#812556: python-qrtools: proposed fix

[Karsten Hilbert]

Package: python-qrtools
Version: 1.4~bzr21-1
Followup-For: Bug #812556

I tested and it is indeed sufficient to change line 181
to use .tobytes() instead of .tostring().

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.5.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 python-qrtools depends on:
ii  python  2.7.11-1
ii  python-imaging  3.2.0-2
ii  python-zbar 0.10+doc-10+b1
ii  qrencode3.4.4-1+b1

python-qrtools recommends no packages.

python-qrtools suggests no packages.

-- no debconf information

Bug#823141: [ricl...@gmail.com: Re: RFP: timeline -- An application to show events on a timeline]]

[Karsten Hilbert]

Word from upstream on package naming:

- Forwarded message from Rickard Lindberg  -

> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823141
> >
> > One problem is that "timeline" is way to generic as a package
> > name. Would you think naming it "thetimelineproj" would fit
> > your vision ?
> 
> I agree that timeline is a too generic name. (The Fedora package is
> actually called 'timeline', but that is not very descriptive.)
> 
> The name 'thetimelineproj' was chosen (I think) because timeline was
> already taken of Sourceforge. It is not really any more descriptive, but a
> bit more unique.
> 
> I've thought about coming up with an entirely new name. It feels natural
> that the name refers to the vision. But our vision is not clearly written
> down anywhere. Perhaps we need to think about this and do some marketing :-)
> 
> I guess that thetimelineproj is fine for now as a package name. Then if we
> change name in the future, we can perhaps also get packages to change the
> name.
> 
> /Rickard

- End forwarded message -

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

Bug#823050: wxglade: cut/paste of items into sizer fails

[Karsten Hilbert]

On Mon, May 02, 2016 at 09:15:49PM +0200, Carsten Grohmann wrote:

> may you add the attached patch to the current Debian package. It fixes
> the bug reported by Karsten as well as a second minor bug in the Perl
> code generator.

Thanks a lot !

> Yes, the fix isn't in a release version yet. The fix is in the stable
> branch of wxGlade.

I see. No rush, I was just making sure I understand correctly.

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

Bug#823050: wxglade: cut/paste of items into sizer fails

[Karsten Hilbert]

Hi Carsten,

> this bug is already fixed in the stable branch of wxGlade 0.7.2 with
> changeset 62797578d6d2 "Fix PyDeadObject errors and crashes during cut
> and paste".

Great !  You mean in an unreleased version thereof ?  Because:

wxglade:
  Installiert:   0.7.2-1
  Installationskandidat: 0.7.2-1
  Versionstabelle:
 *** 0.7.2-1 990
990 ftp://ftp.de.debian.org/debian stretch/main i386 Packages
500 ftp://ftp.de.debian.org/debian unstable/main i386 Packages
100 /var/lib/dpkg/status

> You have three different possibibilties to report wxGlade bugs:
>  - send bug reports to the mailing list,
>  - file a ticket on Sourceforge
> or 
>  - send email to my private email address.

I should've done as I used to do -- email you directly.

Anyway, no harm done.

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

Bug#823141: RFP: timeline -- An application to show events on a timeline

[Karsten Hilbert]

I have made upstream aware of this RFP:

https://sourceforge.net/p/thetimelineproj/mailman/message/35055472/

In particular, "timeline" is way too generic a package name
(although there is no collision ATM).

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

Bug#823050: wxglade: cut/paste of items into sizer fails

[Karsten Hilbert]

Package: wxglade
Version: 0.7.2-1
Severity: normal
Tags: upstream

When cutting/copying, then pasting an item from one position in a sizer
into another position an exception is thrown. Inserting a new item into
the same sizer target position works fine.

Attached find a log file.

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.5.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 wxglade depends on:
ii  python   2.7.11-1
ii  python-wxgtk3.0  3.0.2.0+dfsg-1+b1

wxglade recommends no packages.

wxglade suggests no packages.

-- no debconf information
2016-04-27 15:16:55,391 root INFO: Starting wxGlade version "0.7.2" on Python 
2.7.11+
2016-04-27 15:16:55,478 root INFO: Base directory: 
/usr/share/wxglade
2016-04-27 15:16:55,479 root INFO: Documentation directory:
/usr/share/wxglade/docs
2016-04-27 15:16:55,479 root INFO: Icons directory:
/usr/share/wxglade/icons
2016-04-27 15:16:55,480 root INFO: Build-in widgets directory: 
/usr/share/wxglade/widgets
2016-04-27 15:16:55,480 root INFO: Template directory: 
/usr/share/wxglade/templates
2016-04-27 15:16:55,480 root INFO: Credits file:   
/usr/share/wxglade/CREDITS.txt
2016-04-27 15:16:55,481 root INFO: License file:   
/usr/share/wxglade/LICENSE.txt
2016-04-27 15:16:55,481 root INFO: Manual file:
/usr/share/wxglade/docs/html/index.html
2016-04-27 15:16:55,481 root INFO: Tutorial file:  
/usr/share/wxglade/docs/tutorial.html
2016-04-27 15:16:55,482 root INFO: Home directory: /home/ncq
2016-04-27 15:16:55,482 root INFO: Application data directory: 
/home/ncq/.wxglade
2016-04-27 15:16:55,482 root INFO: Configuration file: 
/home/ncq/.wxglade/wxgladerc
2016-04-27 15:16:55,482 root INFO: History file:   
/home/ncq/.wxglade/file_history.txt
2016-04-27 15:16:55,483 root INFO: Log file:   
/home/ncq/.wxglade/wxglade.log
2016-04-27 15:16:55,484 root INFO: Current locale settings are:
2016-04-27 15:16:55,484 root INFO:   Language code: de_DE
2016-04-27 15:16:55,484 root INFO:   Encoding: UTF-8
2016-04-27 15:16:55,485 root INFO:   Filesystem encoding: UTF-8
2016-04-27 15:16:57,945 root INFO: Python fault handler found and activated
2016-04-27 15:16:58,597 root INFO: Using wxPython 2.8.12.1
2016-04-27 15:16:58,970 root INFO: Loading "wconfig" modules from 
/usr/share/wxglade/widgets/widgets.txt:
2016-04-27 15:16:58,982 root INFO: Module custom_widget.wconfig not found.
2016-04-27 15:16:58,983 root INFO: Module menubar.wconfig not found.
2016-04-27 15:16:58,984 root INFO: Module spacer.wconfig not found.
2016-04-27 15:16:58,985 root INFO: Load code generators:
2016-04-27 15:16:58,991 root INFO:   XRC generator loaded
2016-04-27 15:16:58,998 root INFO:   C++ generator loaded
2016-04-27 15:16:59,002 root INFO:   python generator loaded
2016-04-27 15:16:59,006 root INFO:   lisp generator loaded
2016-04-27 15:16:59,010 root INFO:   perl generator loaded
2016-04-27 15:16:59,010 root INFO: Loading widgets from 
/usr/share/wxglade/widgets/widgets.txt:
2016-04-27 15:16:59,018 root INFO:  frame
2016-04-27 15:16:59,022 root INFO:  dialog
2016-04-27 15:16:59,026 root INFO:  panel
2016-04-27 15:16:59,068 root INFO:  splitter_window
2016-04-27 15:16:59,071 root INFO:  notebook
2016-04-27 15:16:59,075 root INFO:  button
2016-04-27 15:16:59,078 root INFO:  toggle_button
2016-04-27 15:16:59,081 root INFO:  bitmap_button
2016-04-27 15:16:59,084 root INFO:  spin_button
2016-04-27 15:16:59,088 root INFO:  text_ctrl
2016-04-27 15:16:59,091 root INFO:  spin_ctrl
2016-04-27 15:16:59,095 root INFO:  slider
2016-04-27 15:16:59,098 root INFO:  gauge
2016-04-27 15:16:59,101 root INFO:  static_text
2016-04-27 15:16:59,104 root INFO:  checkbox
2016-04-27 15:16:59,107 root INFO:  radio_button
2016-04-27 15:16:59,111 root INFO:  radio_box
2016-04-27 15:16:59,115 root INFO:  choice
2016-04-27 15:16:59,118 root INFO:  combo_box
2016-04-27 15:16:59,121 root INFO:  list_box
2016-04-27 15:16:59,125 root INFO:  check_list_box
2016-04-27 15:16:59,189 root INFO:  calendar_ctrl
2016-04-27 15:16:59,193 root INFO:  generic_calendar_ctrl
2016-04-27 15:16:59,196 root INFO:  datepicker_ctrl
2016-04-27 15:16:59,199 root INFO:  static_line
2016-04-27 15:16:59,202 root INFO:  static_bitmap
2016-04-27 15:16:59,206 root INFO:  list_ctrl
2016-04-27 15:16:59,209 root INFO:  tree_ctrl
2016-04-27 15:16:59,213 root INFO:  grid
2016-04-27 15:16:59,215 root INFO: Module 
property_grid_manager.property_grid_manager not found.
2016-04-27 15:16:59,218 root INFO: