Bug#1063581: gnumed-client: checked by upstream

2024-02-10 Thread 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,

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

2024-02-10 Thread 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

Bug#1005388: gnumed-client: new upstream available

2022-02-12 Thread 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'),

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

2022-01-05 Thread 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,

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

2022-01-05 Thread 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

Bug#988596: akonadi-server: bug still exists

2022-01-03 Thread 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

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

2021-04-17 Thread 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

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

2021-04-16 Thread 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:

Bug#984438: questionable dependency on python3-pip

2021-03-03 Thread 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

Bug#984438: questionable dependency on python3-pip

2021-03-03 Thread 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

Bug#979247: user-manager: holding back upgrade

2021-01-04 Thread 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

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

2020-11-12 Thread 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

2020-11-11 Thread 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,

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

2020-11-11 Thread 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.

Bug#973612: orthanc: libcivetweb version mismatch

2020-11-02 Thread 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

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

2020-10-30 Thread 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,

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

2020-10-26 Thread 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

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

2020-10-26 Thread 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

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

2020-10-24 Thread 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,

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

2020-10-24 Thread 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

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

2020-10-21 Thread 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

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

2020-10-21 Thread 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:

Bug#963738: gnumed-client: new upstream available

2020-06-26 Thread 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

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

2020-06-22 Thread 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

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

2020-05-13 Thread 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

Bug#829380: Orthanc 1.2.0

2020-04-08 Thread Karsten Hilbert
t 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

Bug#829380: Orthanc 1.2.0

2020-04-07 Thread 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 s

Bug#954924: gnumed-client: new upstream 1.8.1

2020-03-25 Thread 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,

Bug#936630: gnumed-client: fixed upstream

2020-02-29 Thread 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

Bug#936631: gnumed-server: fixed upstream

2020-02-29 Thread 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

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

2020-02-28 Thread 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

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

2020-02-27 Thread 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

2020-02-26 Thread 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

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

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

2019-09-15 Thread 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,

Bug#936630: gnumed-client: py3 available upstream

2019-09-15 Thread 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,

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

2019-08-30 Thread 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

Bug#928301: python3-psycopg2: new upstream available

2019-05-01 Thread 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:

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

2018-11-13 Thread 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,

Bug#912118: qrisk2: 2017 upstream release

2018-10-28 Thread 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

Bug#912119: qrisk2: please provide qrisk3

2018-10-28 Thread 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,

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

2018-07-11 Thread 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

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

2018-07-11 Thread 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

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

2018-03-30 Thread 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

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

2018-02-20 Thread 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:

Bug#887887: shutter: new upstream 0.94 available

2018-01-21 Thread 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,

Bug#886567: lshw: problem with memory access

2018-01-07 Thread 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

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

2017-11-03 Thread 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

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

2017-10-19 Thread 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.

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

2017-10-18 Thread 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",

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

2017-10-07 Thread 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"

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

2017-10-07 Thread 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:

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

2017-10-07 Thread 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 ? > > &g

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

2017-10-07 Thread 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

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

2017-10-07 Thread 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:

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

2017-10-07 Thread 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 >

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

2017-10-07 Thread 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 |

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

2017-10-07 Thread 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:

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

2017-04-07 Thread 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:

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

2017-04-05 Thread 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 ?

2017-03-27 Thread 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

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

2017-03-26 Thread 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

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

2017-03-26 Thread 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

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

2017-03-24 Thread 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"

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

2017-03-23 Thread 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

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

2017-03-23 Thread 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

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

2017-03-22 Thread 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 > >

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

2017-03-22 Thread 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

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

2017-03-22 Thread 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

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

2017-03-22 Thread 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

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

2017-03-22 Thread 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,

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

2017-03-08 Thread 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

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

2017-03-08 Thread 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

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

2017-02-02 Thread 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

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

2017-02-02 Thread 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

Bug#829380: Orthanc 1.2.0

2016-12-30 Thread 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: >

Bug#829380: Orthanc 1.2.0

2016-12-29 Thread Karsten Hilbert
s 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

Bug#829380: Orthanc 1.2.0

2016-12-15 Thread 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

Bug#829380: Orthanc 1.2.0

2016-12-14 Thread 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

Bug#829380: Orthanc 1.2.0

2016-12-14 Thread 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.

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

2016-12-11 Thread 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

Bug#838294: dvdisaster: please consider packaging

2016-11-16 Thread 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

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

2016-07-24 Thread 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,

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

2016-07-23 Thread 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

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

2016-07-23 Thread 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

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

2016-07-02 Thread 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:

Bug#829380: orthanc: example upgrade script

2016-07-02 Thread 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')

Bug#829380: orthanc: please provide orthanc_upgrade script

2016-07-02 Thread 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

Bug#818757: orthanc-postgresql: is resolved

2016-07-02 Thread 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

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

2016-06-29 Thread 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

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

2016-06-29 Thread 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 >

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

2016-06-29 Thread 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

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

2016-06-29 Thread 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)

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

2016-06-28 Thread 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

Bug#812556: python-qrtools: proposed fix

2016-06-04 Thread 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,

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

2016-05-09 Thread 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

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

2016-05-02 Thread 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

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

2016-05-02 Thread 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

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

2016-05-01 Thread 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

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

2016-04-30 Thread 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 --

  1   2   3   4   5   >