>> After downloading the source code of each package, create a "Build"
>> directory inside, and run:
>>
>> # cmake .. -DSTATIC_BUILD=ON -DCMAKE_BUILD_TYPE=Debug
>> # make
>
> 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
>
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
>
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.
Yes, sorry about that: As
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
> - 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
exact way of reproducing
this issue?
Regards,
Sébastien-
- Mail original -
> De: "Karsten Hilbert" <karsten.hilb...@gmx.net>
> À: 818...@bugs.debian.org
> Envoyé: Mardi 19 Avril 2016 11:34:17
> Objet: [Debian-med-packaging] Bug#818757: orthanc-postgresql: does n
Hello,
> > Is there anything else I can provide to get this bug looked at ?
>
> Even if I risk to be a pain in the behind - since this
> package is of such importance to responsible Medical Care
> I allow myself to re-inquire about the state of this bug.
Unfortunately, this item is low-priority
Hi Sébastien,
welcome back.
> I am back from vacations. I will look at the upgrade problem as soon as
> possible.
I don't think it is an upgrade problem.
> As a quick hack to unblock you,
Fortunately, this is on a testing machine. No production data
at risk - that instance still runs on
Hello Karsten,
> Is there anything else I can provide to get this bug looked at ?
I am back from vacations. I will look at the upgrade problem as soon as
possible.
As a quick hack to unblock you, I would suggest to apply the "Generic
replication" procedure [1]. In your case, the procedure
On Sun, Mar 20, 2016 at 05:55:10PM +0100, Sébastien Jodogne wrote:
> > 4) the existing orthanc_db is 0.8 and the jump is to Orthanc 1.0 (orthanc-pg
> > 2.0)
>
> Have you added the "--upgrade" option so that Orthanc would automatically
> upgrade the database schema?
I now did run Orthanc with
On Sun, Mar 20, 2016 at 05:55:10PM +0100, Sébastien Jodogne wrote:
> > 4) the existing orthanc_db is 0.8 and the jump is to Orthanc 1.0 (orthanc-pg
> > 2.0)
>
> Have you added the "--upgrade" option so that Orthanc would automatically
> upgrade the database schema?
I have not because
- it's
Hello,
> 4) the existing orthanc_db is 0.8 and the jump is to Orthanc 1.0 (orthanc-pg
> 2.0)
Have you added the "--upgrade" option so that Orthanc would automatically
upgrade the database schema?
Sébastien-
12 matches
Mail list logo
