Re: Aw: Aw: Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Samstag, 2. Januar 2021, 19:02:59 CET schrieb Sebastian Hilbert:
> The company being acquired is correct. The license stuff is a different
> story. The license check might entirely happen in their commercial
> software. In other words talking to the device might be possible without
> any license check. If one knows how to talk to the device.
>

I had contacted an ebay seller that sells repaired devices. They state that a
new license is 75 $ and one needs to reinstall (IOW buy a new license) when
you move to another computer with the same sensor. They recommend a laptop :-)

They also state that there is some sort of server setup where you could use
the sensor from multiple computers on a network with one license.

I have no idea what clues that gives. First info seems to imply the license is
specific to the computer.

Best,
SH

Aw: Aw: Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

 
 If someone else had a sensor and could make the current code work as is,  this would exclude a license in unique to the sensor--Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.Am 02.01.21, 18:55 schrieb Karsten Hilbert :

  Given this (page 5)
  
   https://www.atlasresell.com/sites/default/files/KodakTrophyWindowsGuide.pdf
  
   I've got a theory on the two devices:
  
   Once upon a time an x-ray sensor was developed and
   certified by Trophy.
  
   Later, Trophy was acquired by Kodak.
  
   Eventually, Kodak started marketing its sensor via CareStream.
  
   Kodak wanted its RVG5200 to be branded "Kodak" (as in:
   it shows up as "Kodak" on the USB bus).
  
   Removing the Trophy USB IDs from the hardware and putting in the
   Kodak USB IDs may have carried the risk of needing to re-certify
   the device (even though it did not technically change).
  
   So, for re-branding, Kodak simply put a USB veil (fake device)
   "covering" the unchanged Trophy USB device.
  
   If that theory holds I find it reasonable to assume that
   the license checks happens in the *first* part of the init,
   the Kodak device one.
  
   Does that make any sense ?
  
   Karsten
  
  
 

Aw: Aw: Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

 
 The company being acquired is correct. The license stuff is a different story. The license check might entirely happen in their commercial software. In other words talking to the device might be possible without any license check. If one knows how to talk to the device.This theory would have to be checked with a 3rd party software that officially supports the device - if such a thing exists.--Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.Am 02.01.21, 18:55 schrieb Karsten Hilbert :

  Given this (page 5)
  
   https://www.atlasresell.com/sites/default/files/KodakTrophyWindowsGuide.pdf
  
   I've got a theory on the two devices:
  
   Once upon a time an x-ray sensor was developed and
   certified by Trophy.
  
   Later, Trophy was acquired by Kodak.
  
   Eventually, Kodak started marketing its sensor via CareStream.
  
   Kodak wanted its RVG5200 to be branded "Kodak" (as in:
   it shows up as "Kodak" on the USB bus).
  
   Removing the Trophy USB IDs from the hardware and putting in the
   Kodak USB IDs may have carried the risk of needing to re-certify
   the device (even though it did not technically change).
  
   So, for re-branding, Kodak simply put a USB veil (fake device)
   "covering" the unchanged Trophy USB device.
  
   If that theory holds I find it reasonable to assume that
   the license checks happens in the *first* part of the init,
   the Kodak device one.
  
   Does that make any sense ?
  
   Karsten
  
  
 

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Samstag, 2. Januar 2021, 09:34:52 CET schrieb Sonali Warunjikar:
> On Sat, Jan 02, 2021 at 01:32:32PM +0530, Sonali Warunjikar wrote:
> > Have to also check whether the pypng package supports that field.
>
> [1] confirms the pixel size to be 19 micro. pypng does have a way to
> supply it. Now it's reporting sensible distances, but have to check and
> see if there are calibration issues.
>
> BTW any idea, what "True (measured) resolution = 16lp/mm" means in [1]? It
> seems it's called line pairs per mm. Not sure how to correlate it with 19
> micro pixel size.
>
> [1]
> https://pdf.indiamart.com/impdf/22884448473/MY-16502350/dental-rvg-systems-k
> odak-5200.pdf

Maybe this is of any help :

https://www.pco.de/fileadmin/user_upload/knowledge_base/
kb_about_resolution_V101.pdf[1]

"The maximum spatial resolution is described as ability to separate patterns of 
black and
white lines and it is given in line pairs per millimeter ([lp/mm]). As 
theoretical limit it is
described in the literature and com-prehensive that the maximum resolution is 
achieved
if one black line is imaged on one pixel while one white line is imaged to the 
neighbor
pixel."





[1] https://www.pco.de/fileadmin/user_upload/knowledge_base/
kb_about_resolution_V101.pdf

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Freitag, 1. Januar 2021, 09:34:58 CET schrieb Sonali Warunjikar:
> On Fri, Jan 01, 2021 at 08:28:21AM +0100, Karsten Hilbert wrote:
> > > Yes, it's now closer to a real X ray. The Dr still sees some problems,
> > > but
> > > I think it will need some experiments with exposure, brightness and
> > > contrast.
> >
> > Typically, there's presets for those but as a doctor one always plays
> > with them such settings during the diagnostics process.
> >
> > So, I suppose finding suitable defaults is useful but then
> > one should strive to convert the data to a more conventional
> > format, say, some DICOM variant and feed that to Orthanc for
> > storage and to Ginkgo CADx / Aeskulap / your-favourite-viewer
> > for image display. They offer controls for adjusting exposure,
> > brightness, and contrast.
> >
> > I can ascertain one _needs_ to adjust those dynamically :-)
>
> What I am told is, the defaults of the proprietary software are pretty
> good and often don't need much adjustment. But with the images we are
> getting now we tried in gimp and exposure, brightness, contrast could be
> adjusted to get satisfactory view. Probably those settings should be
> applied to the image up front (say using ImageMagick or otherwise) -
> besides the viewer will have those options.
>
> I am not finding a case for taking pains to convert it to DICOM as long as
> I get all the controls over a png - for example with gimp. Some advance
> use cases in other walks of radio imaging benefit (3D, playing a sequence
> of images etc) but for general dentistry not sure whether we need those.

The use case for converting to DICOM _could_ be :

1.) standard based "image" storage and sharing
2.) image manipulation with standard (any) DICOM viewer out there

Tools like this make the conversion process easy

https://support.dcmtk.org/docs-dcmrt/img2dcm.html[1]

or this

https://github.com/pydicom/pydicom/issues/939[2]


[1] https://support.dcmtk.org/docs-dcmrt/img2dcm.html
[2] https://github.com/pydicom/pydicom/issues/939

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Donnerstag, 31. Dezember 2020, 12:05:18 CET schrieb Sonali Warunjikar:
> On Thu, Dec 31, 2020 at 02:15:33PM +0530, Sonali Warunjikar wrote:
> > Now the USB layer is as such over. The challenge now shifts to the format
> > of the data gathered.
>
> Almost there...
>
> The image resolution on Windows is known and the byte array gathered is
> double of widthxheight indicating it's a 16 bit grayscale image and the
> following way to build image using Pillow almost works - as in the shape
> of the x rayed finger is fine.

That sounds terrific.

>
> Image.frombytes('L',(1168,1562),buf,'raw','L;16B',0,1)
>
> Only problem left if I save it back as a raw bitmap (just to see how much
> size a lossless format gives) it is of half the number of bytes gathered
> from which it seems it's not using full 16 bit range. The X ray quality in
> turn is affected.
>
> How to make Pillow consume all 16 bits per pixel is unclear. Whether L;16B
> is right or not I am unsure.

This might be a limitation introduced by Pillow. I admit that I do not fully 
understand the
problem but briefly looking up some references I came across

https://www.researchgate.net/publication/
307613633_Comparison_of_the_performance_of_intraoral_X-
ray_sensors_using_objective_image_quality_assessment[1]

and

https://stackoverflow.com/questions/32622658/read-16-bit-png-image-file-using-python[2]

I know that ImageJ is used a lot for Dicom images

maybe this helps.
https://forum.image.sc/t/how-can-i-import-a-raw-image-in-imagej/36435[3]

Other then that it migh be neccessary to decompile the Windows binary to get 
some
pointers.


[1] https://www.researchgate.net/publication/
307613633_Comparison_of_the_performance_of_intraoral_X-
ray_sensors_using_objective_image_quality_assessment
[2] 
https://stackoverflow.com/questions/32622658/read-16-bit-png-image-file-using-python
[3] https://forum.image.sc/t/how-can-i-import-a-raw-image-in-imagej/36435

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Mittwoch, 30. Dezember 2020, 05:25:54 CET schrieb Sonali Warunjikar:
> On Wed, Dec 30, 2020 at 12:38:53AM +0100, Karsten Hilbert wrote:
> > I agree. It seems quite likely to be more setup of the device.
> 
> To be precise I do not know how to issue two back to back 'S' without a
> 'C' occurring in between.
> 
> 1.007.001 S Ii 0002
> 1.007.000 S Ci 0342 c0 83 0008  0342
> 
> That's the only difference left between the two traces. Does it look like
> multithreading is required for it - i.e. issue 'S Ii' with a timeout and
> in parallel (but after 'S Ii' is issued) do rest of the things and then
> sync with 'C Ii'?
> 
> On the face of it, it's weird if multithreading is required for a serial
> communication where there is one link and two devices at both ends of it.
> But may be the device is designed to not respond to Ii until it sees those
> Cis (or timeout).
> 
> Will try anyway.

shouldn't it be possible to find "repetition" when taking images - if  feasible 
? It should be 
possible to at least identify (even with fuzzy start and end) "data blocks". 
Once data blocks 
are identified the "stuff inbetween" should be most interesting to identify 
what happens. 
Given that nothing happens in "idle state", this should identify the 
communication from 
end of image acquistion to "next image". Theoretically replaying that should 
trigger a new 
image acquisition.

The key seems to be understanding what exactly is going on.

A piece from the person the reverse engineered the Kinect

https://fahrplan.events.ccc.de/congress/2011/Fahrplan/attachments/2005_slides.pdf[1]
 

likely, there are more recent hardware, software solutions but ...

Step 1: get dataHardware loggers:
TotalPhase Beagle 480
OpenVizsla –http://openvizsla.org/

Software loggers:
BusDog – Windows USB filter driver http://code.google.com/p/busdog/
/dev/usbmon

Step 2: understand data
Download/extract TotalPhase Data Center for your 
platform:http://www.totalphase.com/
products/datacenter/

Get USB trace from someone who bought a Beagle 480:git clone 
git://github.com/adafruit/
Kinect.gitIOpenKinect/USBlogs/enuminit.tdcwith Data Center
Start reading 



[1] 
https://fahrplan.events.ccc.de/congress/2011/Fahrplan/attachments/2005_slides.pdf

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Sonntag, 27. Dezember 2020, 17:05:16 CET schrieb Sonali Warunjikar:
> On Sun, Dec 27, 2020 at 03:53:36PM +0100, Sebastian Hilbert wrote:
> > > Will update the thread when some progress is made. Looks like as far as
> > > the basic knowhow is concerned, I may not have too many more questions.
> >
> > Sounds good. Persistence will pay off.
>
> Something remarkable happened. After playing back the initialization
> sequence the usb device talked with till that point _disappears_ (not seen
> in lsusb any more) and a new device with a different vendor:product (ID
> 082b:100a Trophy RVG 5200/6200) makes an appearance. Looks like rest of it
> is to spoken with the new device.
>
> I do not know how common the practice is and what's the reason - probably
> obfuscation, probably something to do with design of the device.

Can you clearly identify the end of this initial transmission and some sort of
resting state ? In other word the exact endpoint before image is requested
from the device. I guess you would have to plug/unplug a couple times and find
the point when the initialization is finished.

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Sonntag, 27. Dezember 2020, 17:05:16 CET schrieb Sonali Warunjikar:
> On Sun, Dec 27, 2020 at 03:53:36PM +0100, Sebastian Hilbert wrote:
> > > Will update the thread when some progress is made. Looks like as far as
> > > the basic knowhow is concerned, I may not have too many more questions.
> >
> > Sounds good. Persistence will pay off.
>
> Something remarkable happened. After playing back the initialization
> sequence the usb device talked with till that point _disappears_ (not seen
> in lsusb any more) and a new device with a different vendor:product (ID
> 082b:100a Trophy RVG 5200/6200) makes an appearance. Looks like rest of it
> is to spoken with the new device.
>
> I do not know how common the practice is and what's the reason - probably
> obfuscation, probably something to do with design of the device.

I consider this to be some sort of obfuscation. Sometime they even send a PIN
this way. This was recently discovered in some German Chipcard readers.

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Sonntag, 27. Dezember 2020, 13:09:20 CET schrieb Sonali Warunjikar:
> On Sun, Dec 27, 2020 at 11:32:10AM +0100, Karsten Hilbert wrote:
> > Very nice !
>
> I figured out more things, mainly the answers to confusions I had in the
> last mail. The answers to my questions are:
>
> Host always initiates the interaction. It is called 'i' if host is seeking
> information and not sending any data. It is called 'o' if host is sending
> data to the device. The 'o' requests are associated with data.
>
> I am now able to play back the entire control sequence from os
> initializing the device generically to the app initializing it. I'll
> systematically write this code as a playback a recorded usbmon trace
> (untruncated one, thanks to the citation in previous post).
>
> Then 2 things remain:
>
> - non control interactions (mainly I and B type for this device)
>
> - figuring out variable part of the whole interaction and parameterizing
>   it
>
> Will update the thread when some progress is made. Looks like as far as
> the basic knowhow is concerned, I may not have too many more questions.

Sounds good. Persistence will pay off.

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Sonntag, 20. Dezember 2020, 04:37:21 CET schrieb Sonali Warunjikar:
> On Sat, Dec 12, 2020 at 11:49:16PM +0100, Sebastian Hilbert wrote:
> > LK-C64 from YesBiotech from South Korea.
> >
> > Sold on alibaba.com
>
> Summary:
>
> 1. I finally found an English page and have sent a query.
>
> 2. I sent a query to the manufacturer (2nd time around) and like before no
> response. There is no hope from the retailers, I mentioned.
>
> 3. On sane-devel mailing list the thread hasn't gone further. The protocol
> could not be easily recognized is what the thread status is.
>
> 4. My attempts to mimic the wireshark interactions lead to input/output
> error or timeout error. Could not draw any other response from the device.

Unfortunately this is where it often ends unless someone comes around with 
advanced
knowledge on USB commonication.

Those people often sit in labs of technical universities or in the back of 
radio repair shops.
Unfortunately, getting a hold of them is the tricky part.

If you want to spend more enery you could try to contact hardware tinkerers 
from local
Makerspaces if such a thing exists.

I guess the next step would be to obtain a hardware USB debugger like the ones 
I have
referenced. They are around $100 US and come bundled with software that makes
capturing reliable.

https://www.bugblat.com/products/ezsniff/index.html[1]

There are some videos on USB reverse engineering from the Chaos Computer Club in
Germany

https://www.youtube.com/watch?v=jMf55KVDPaE[2]

https://www.youtube.com/watch?v=LL7sFLJZOjM[3]

More often then not, it will be - you - who becomes the expert and masters the 
art.

Read 
https://hackernoon.com/usb-reverse-engineering-down-the-rabbit-hole-c4809a5b55c4[4]
  and you might just find a pointer to tools or people that might be able
to help.


[1] https://www.bugblat.com/products/ezsniff/index.html
[2] https://www.youtube.com/watch?v=jMf55KVDPaE
[3] https://www.youtube.com/watch?v=LL7sFLJZOjM
[4] 
https://hackernoon.com/usb-reverse-engineering-down-the-rabbit-hole-c4809a5b55c4

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Sonntag, 13. Dezember 2020, 14:59:40 CET schrieb Sonali Warunjikar:
> On Sun, Dec 13, 2020 at 02:47:15PM +0100, Sebastian Hilbert wrote:
> > If you want to try talking to the device look at
> >
> > https://github.com/JohnDMcMaster/usbrply[1]
>
> Present worry is getting reliable data to replay in the first place. As I
> said usbmon truncates bytes and I have several observations to believe
> that wireshark data is not reliable - even the endpoints it claims to have
> talked with are not present in lsusb output of the same device. Its export
> is totally buggy as well.
>
> Hence I'll try binary interface of usbmon next time around which will be
> (hopefully) more reliable.
>
> > I wonder how you would be able to see that something is happening. Is
> > there an LED that provides feeback ?
>
> At present, if anything other than 'Input/Output Error' or 'Timeout'
> occurs I'd consider that as progress! I don't think 'read' is a problem
> itself and it's unlikely that I'll miss the data that is returned - of
> course I can confirm that only after going past these errors.

If software capture is a pain maybe hardware can help.

https://www.bugblat.com/products/ezsniff/index.html[1]

or

https://www.bugblat.com/products/minisniff/index.html[2]

Seems like they are around $100 including shipping. Not exactly cheap but if it 
works and
saves you hours of wasted time 

There is always ebay to sell it once you are done :-)

I am sure there are other solutions as well.



[1] https://www.bugblat.com/products/ezsniff/index.html
[2] https://www.bugblat.com/products/minisniff/index.html

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Sonntag, 13. Dezember 2020, 13:54:22 CET schrieb Sonali Warunjikar:
> On Sun, Dec 13, 2020 at 12:51:34PM +0100, Sebastian Hilbert wrote:
> > Have you asked the manufacturer for information on using this as a twain
> > device ?
> I thought I replied to that. This product's pages open only in German even
> if I search on the English site. So could not find where to ask.
>
> For the encouraging words, thanks. I'll keep it up.
>
> As I mentioned the glaring gaps between wireshark and usbmon and quality
> issues with the former are disappointing and so is the word length limit
> in usbmon.
>
> Next time I take this up, I'd use the binary interface of usbmon to get
> more reliable (hopefully) and complete data - probably next weekend.
>
> Also, will try and call ioctl directly in C when experimenting to avoid
> any possibility of pyusb doing something wrong (this is not meant to
> suspect so, just reducing the layers in between to reduce things that can
> possibly hinder something).
>
> Will try and ask on sane mailing lists in the meantime. Thanks for the
> suggestion and all other pointers.

If you want to try talking to the device look at

https://github.com/JohnDMcMaster/usbrply[1]

Would be interesting to see if you can replay a captured USB session.

I wonder how you would be able to see that something is happening. Is there an 
LED that
provides feeback ?

In the worst case it does something (capture an image) but you will not notice. 
I guess it
would return raw image data but there is no process to receive it.



[1] https://github.com/JohnDMcMaster/usbrply

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Sonntag, 13. Dezember 2020, 13:54:22 CET schrieb Sonali Warunjikar:
> On Sun, Dec 13, 2020 at 12:51:34PM +0100, Sebastian Hilbert wrote:
> > Have you asked the manufacturer for information on using this as a twain
> > device ?
> I thought I replied to that. This product's pages open only in German even
> if I search on the English site. So could not find where to ask.
>
> For the encouraging words, thanks. I'll keep it up.
>
> As I mentioned the glaring gaps between wireshark and usbmon and quality
> issues with the former are disappointing and so is the word length limit
> in usbmon.

I found a reference that the default usbmon is not suitable and one should use 
a different
one.

Will try to dig up the link

Here you should be able to get in touch with the manufacturer

https://www.carestreamdental.com/en-us/about/contact-us/[1]

They are explicetly stating TWAIN compliance and 3rd party interaction.

I guess they hand out a twain driver on request.

Best,
SH


[1] https://www.carestreamdental.com/en-us/about/contact-us/

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Sonntag, 13. Dezember 2020, 13:54:22 CET schrieb Sonali Warunjikar:
> On Sun, Dec 13, 2020 at 12:51:34PM +0100, Sebastian Hilbert wrote:
> > Have you asked the manufacturer for information on using this as a twain
> > device ?
> I thought I replied to that. This product's pages open only in German even
> if I search on the English site. So could not find where to ask.
>
> For the encouraging words, thanks. I'll keep it up.
>
> As I mentioned the glaring gaps between wireshark and usbmon and quality
> issues with the former are disappointing and so is the word length limit
> in usbmon.
>
> Next time I take this up, I'd use the binary interface of usbmon to get
> more reliable (hopefully) and complete data - probably next weekend.
>
> Also, will try and call ioctl directly in C when experimenting to avoid
> any possibility of pyusb doing something wrong (this is not meant to
> suspect so, just reducing the layers in between to reduce things that can
> possibly hinder something).
>
> Will try and ask on sane mailing lists in the meantime. Thanks for the
> suggestion and all other pointers.

I know that all the pointers get overwhelming. What you are looking at is way 
beyond my
expertise.

I was hoping that capturing and replaying usb traffic would get you somewhere.

For what it's worth I found this video on youtube.

https://www.youtube.com/watch?v=8isjb4HsS9k[1]

Lots of interesting information on a Kodak 6100.



[1] https://www.youtube.com/watch?v=8isjb4HsS9k

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Sonntag, 13. Dezember 2020, 05:43:39 CET schrieb Sonali Warunjikar:
> On Sat, Dec 12, 2020 at 05:59:38PM +0100, Karsten Hilbert wrote:
> > You may want to capture USB traffic during *startup* of the
> > Windows app, not before exposure only. It may well send setup
> > commands at that point.
>
> Sorry, I said earlier I captured from the start of windows VM. But may be
> I erred. I have recaptured just the initial part and attached herewith.
>
> A bit intimidating...

Briefly looked at what you captured.

Is it reproducable ?

I mean, shouldn't it be possibel to capture certain events.

Start capture, plug device in, remove device
repeat.

Once you start seeing a pattern, you get a feeling for what happens when.

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Sonntag, 13. Dezember 2020, 11:01:35 CET schrieb Sonali Warunjikar:
> On Sun, Dec 13, 2020 at 12:06:22PM +0530, Sonali Warunjikar wrote:
> > Also a wireshark capture (attached, gzipped), a filter 'usb.bus_id == 1
> > and usb.device_address == 6' reveals the device in question.
> >
> > Honestly no clue how I'll make use of all this!
> >
> > Would appreciate help.
>
> Strangely the endpoint numbers in usbmon and in wireshark mismatch.
> Wireshark shows endpoint numbers that are not even shown by lsusb in some
> cases. Don't know which ones to trust, probably usbmon as it matches
> lsusb, but usbmon truncates all the data.
>
> Wireshark probably has a bug that greys out export format options which
> makes it difficult to export all the bytes data. Still managed to get
> those out once (something I can't repeat now).
>
> But sending those bytes as it is to the device to begin the interaction
> draws either input/output error or requested timed out depending on
> whether set_altsettings() was called on the interface or not.
>
> Search for twain on Linux led nowhere. There is a pint sane backend that
> is supposed to mimic twain, but that doesn't seem to recognize on
> scanimage -L.
>
> Sadly, considering giving up...

Never give up. Consider asking people with more knowledge on the SANE mailing 
list

http://www.sane-project.org/mailing-lists.html[1]

Present your findings and someone might immediately have further pointers.

The sensor is more or less a camera that registers light that is emited when 
xray hits the
sensor.

The so called sensor is a highly integrated package with most of the smarts 
inside the
sensor head.

From what I read it is always on meaning once plugged into USB it is ready to 
transmit.
Just like your average webcam.

The trick now is to read the data off the sensor. Supposedly it gives a 
continous stream
and it is up to the receiving software to make some sense out of this.

For different sensor there is some interesting information here

https://revengic.blogspot.com/2019/03/gxs-700-memories.html[2]

https://revengic.blogspot.com/2019/03/gxs-700-internals.html[3]

Have you asked the manufacturer for information on using this as a twain device 
?





[1] http://www.sane-project.org/mailing-lists.html
[2] https://revengic.blogspot.com/2019/03/gxs-700-memories.html
[3] https://revengic.blogspot.com/2019/03/gxs-700-internals.html

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Samstag, 12. Dezember 2020, 18:12:20 CET schrieb Sonali Warunjikar:
> On Sat, Dec 12, 2020 at 06:03:04PM +0100, Sebastian Hilbert wrote:
> > You might already be aware of this ressource
> >
> > https://www.devalias.net/devalias/2018/05/13/usb-reverse-engineering-down-> 
> > > the-rabbit-hole/[1]
> No I wasn't. Thanks for another great pointer.

It looks like this thing was formerly know as

Kodak Trophy RVG (sensor)

It actually seems to be

LK-C64 from YesBiotech from South Korea.

Sold on alibaba.com

https://german.alibaba.com/product-detail/lk-c64-rvg-5200-x-ray-sensor-dental-digital-x-ray-sensor-60431854823.html[1]

I could not find any useful information on the sensor or USB protocol. 
Sometimes the
seller on alibaba are quite supportive when they are asked for technical 
documentation.

Might be worth a try.


[1] 
https://german.alibaba.com/product-detail/lk-c64-rvg-5200-x-ray-sensor-dental-digital-x-ray-sensor-60431854823.html

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Samstag, 12. Dezember 2020, 17:30:54 CET schrieb Sonali Warunjikar:
> On Sat, Dec 12, 2020 at 09:10:21PM +0530, Sonali Warunjikar wrote:
> > Next step requires going to clinic and exposing it to xray and see what
> > happens. Will update soon.
>
> No luck. For the same end point that showed data being received in usbmon,
> the read call times out even after X ray exposure.
>
> So some protocol is involved - something to be sent to the device prior to
> exposure. Will try to figure out.

You might already be aware of this ressource

https://www.devalias.net/devalias/2018/05/13/usb-reverse-engineering-down-the-rabbit-hole/[1]



[1] 
https://www.devalias.net/devalias/2018/05/13/usb-reverse-engineering-down-the-rabbit-hole/

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Samstag, 12. Dezember 2020, 06:59:26 CET schrieb Sonali Warunjikar:
> On Fri, Dec 11, 2020 at 07:22:21PM +0100, Karsten Hilbert wrote:
> > http://vusb-analyzer.sourceforge.net/
>
> Due to pygtk requirement not being met on my ubuntu 20.04 above doesn't
> work. Yes there are quirks to get it to work. But for now I am comfortable
> looking at usbmon also and do some experiments. If they don't work I'll
> get into the quirks.
>
> Thanks for all the pointers.

For scanning you might want to look at

https://pypi.org/project/pyScanLib/[1]

and

https://github.com/soachishti/autoScanner[2]



[1] https://pypi.org/project/pyScanLib/
[2] https://github.com/soachishti/autoScanner

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Samstag, 12. Dezember 2020, 06:59:26 CET schrieb Sonali Warunjikar:
> On Fri, Dec 11, 2020 at 07:22:21PM +0100, Karsten Hilbert wrote:
> > http://vusb-analyzer.sourceforge.net/
>
> Due to pygtk requirement not being met on my ubuntu 20.04 above doesn't
> work. Yes there are quirks to get it to work. But for now I am comfortable
> looking at usbmon also and do some experiments. If they don't work I'll
> get into the quirks.
>
> Thanks for all the pointers.

Found a presentation that says it is Twain compatible and works with third party
applications

https://de.slideshare.net/smokeypike/the-rvg-5200-from-carestream-dental-digital[1]

Does it use a twain driver on Windows ?

Here is a pointer to USB capture and replay.

https://github.com/JohnDMcMaster/usbrply[2]

It has some pointers on how to get you going.

Sample workflow for capturing Windows traffic and replaying traffic in Python:
 *  Install Wireshark. Make sure you install the USBPcap library
 *  Start Wireshark
 *  Connect USB device to computer
 *  Start catpure
 *  Start your application, do your thing, etc to generate packets
 *  Close application
 *  Stop capture
 *  Save capture. Save in pcap-ng format (either should work)
 *  Close Wireshark
 *  Run: "usbrply --device-hi -p my.pcapng >replay.py"
 *  Linux: run "python replay.py"
 *  Verify expected device behavior. Did an LED blink? Did you get expected 
data back?
Now, that sounds interesting.



[1] 
https://de.slideshare.net/smokeypike/the-rvg-5200-from-carestream-dental-digital
[2] https://github.com/JohnDMcMaster/usbrply

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Samstag, 12. Dezember 2020, 17:30:54 CET schrieb Sonali Warunjikar:
> On Sat, Dec 12, 2020 at 09:10:21PM +0530, Sonali Warunjikar wrote:
> > Next step requires going to clinic and exposing it to xray and see what
> > happens. Will update soon.
>
> No luck. For the same end point that showed data being received in usbmon,
> the read call times out even after X ray exposure.
>
> So some protocol is involved - something to be sent to the device prior to
> exposure. Will try to figure out.

I vaguely remember some Windows tool that allowed to capture an USB
communication and replay it.

By doing that you might be able to do some test runs and see what changes. If
it is the same patient it might be just the data that is different for different
traces.

Can you share a usbmon recording ? I cannot promise to be of much help but it
sure sounds interesting.

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Samstag, 12. Dezember 2020, 06:59:26 CET schrieb Sonali Warunjikar:
> On Fri, Dec 11, 2020 at 07:22:21PM +0100, Karsten Hilbert wrote:
> > http://vusb-analyzer.sourceforge.net/
>
> Due to pygtk requirement not being met on my ubuntu 20.04 above doesn't
> work. Yes there are quirks to get it to work. But for now I am comfortable
> looking at usbmon also and do some experiments. If they don't work I'll
> get into the quirks.

There seems to be a deb for that

http://archive.debian.org/debian-archive/debian/pool/contrib/v/vusb-analyzer/[1]

That makes the cmdline interface work it seems.

Now it works without the gtk interface but that is not desirable.

It is missing gnomecanvas which is apparently satisfied by python-gnome2

which is not available after Debian jessie.

Disclaimer: it may break your system

I added deb http:///cz.archive.ubuntu.com/ubuntu/ bionic main universe

to the sources list and installed the dependencies without a hitch.


[1] 
http://archive.debian.org/debian-archive/debian/pool/contrib/v/vusb-analyzer/

Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

Am Samstag, 12. Dezember 2020, 06:54:29 CET schrieb Sonali Warunjikar:
> On Fri, Dec 11, 2020 at 10:42:23PM +0530, Sonali Warunjikar wrote:
> > What is unclear is e.g. '57856 = ' is supposed to indicate length of the
> > data that follows but it's not exactly 57856 bytes following it on that
> > event (line).
>
> It seems, no matter the data length, usbmon truncates it to 32 bytes and
> someone here[1] confirms that. Never mind, I think it still gives an idea.
>
> [1] https://mrmekon.tumblr.com/post/5146693470/usbmon-truncation

Nice catch. I would be awesome if you could free your device.

Aw: Re: Acquiring Dental RVG on Linux

[Sebastian Hilbert]

How is the machine connected ? USB ? Network ?

 

What are the resulting files you get on disk with the Windows software or is it stored in a database ?

 

I might be worth looking into how the software actually finds out the hardware has changed. They might check the MAC address of the network card.

 
 

Gesendet: Freitag, 11. Dezember 2020 um 10:09 Uhr
Von: "Sonali Warunjikar" 
An: debian-med@lists.debian.org
Betreff: Re: Acquiring Dental RVG on Linux

On Fri, Dec 11, 2020 at 08:48:21AM +0100, Karsten Hilbert wrote:
> The windows imaging application might work under Wine, or be
> put into a VM, and might possibly store the imaging results
> in a somehow accessible format, which you might be able to
> further process on the Linux side.

Yes, my setup is precisely that right now. A VirtualBox windows instance
on Linux host and shared samba file system over which I can get the images
back to Linux.

However the license of the proprietary software is node locked which does
not allow me to change the VM. For example I can't even switch from
virtualbox to qemu or something else that might suit me. Tried porting the
vm to qemu, but windows always finds that as if the motherboard has
changed and refuses to boot. If I do a fresh installation I'll have to buy
the software license all over again every time I do so.

You mentioned DICOM - is it a protocol to talk to digital x ray device? If
there are any resources kindly do share. I'll also search.
 

Re: FreeMedForms projet

[Sebastian Hilbert]

Hi,

I can try to imagine what you are going through. What do you mean by 
"documentation is not available" ?

Best,
Sebastian

Am Freitag, 10. Januar 2020, 17:34:35 CET schrieb Eric Maeker:
> Oh! There is a misunderstanding here!
> Let me correct my words:
> -> full code of each stable released version is packaged and freely
> available (but undocumented since v1.0.0).
> 
> Code is considered 100% stable (and released) when :
> - it perfectly passes every the unit-tests in debug mode with MacOs,
> Win32/64, Debian 64,
> - it perfectly builds in each platform and
> - it perfectly passes manual tests on the release bin for each platform.
> Manual tests are available on our main website : freemedforms.com
> -> This is because we do not have time to test and pack all sub-versions
> like before.
> Currently v1.1.0 does passes all tests under MacOs, does build correctly on
> Debian in debug mode but not in release, and is not tested on Win32/64
> (build process, unit-tests, installation process, config process...)
> because WinDevs quit the project. So it is considered as a pre-version
> available only to testers (MacOs).
> 
> We know that at least two forks exists (this is what our private data
> server's log tells us). We do not receive any patch, invitation to git
> repos, or any kind of official informations or queries.
> 
> In consequence, we decide that our git repository will not be freely
> accessible. Approval does only concern the FreeMedForms' git and the
> ability to join the project as member (coder, tester, communication
> manager...).
> 
> I hope that the situation is clearer for you.
> 
> Belle journée
> Cordialement
> 
> 
>  *Dr Maeker Éric*
> 
> *Gériatre, psychogériatre*
> eric.mae...@gmail.com
> Twitter  @DrMaeker 
> RPPS 10002307964
> 
> maeker.fr  Site personnel
> empathies.fr  Association Emp@thies
> freemedforms.com  Logiciel médical
> 
> La gériatrie, c'est la médecine pour les pères et les mères Noël
> 
> 
> Le ven. 10 janv. 2020 à 14:26, Daniel Hakimi  a
> 
> écrit :
> > If the package is available under the GPL, it strikes me that requiring
> > any non-trivial approval to obtain source under that license would not be
> > allowed. If the form is just a check box verifying that you have received
> > object code, maybe, but this sounds like it may be a license violation.
> > Can
> > we clarify what the approval process entails? How much information is
> > required, and for what reasons might people be rejected?
> > 
> > However, if some third party were to obtain this source, build from it,
> > and make it available, that version of the code would be perfectly Free.
> > 
> > On Fri, Jan 10, 2020, 08:15 Andreas Tille  wrote:
> >> On Fri, Jan 10, 2020 at 07:45:34AM -0500, Daniel Hakimi wrote:
> >> > Can you please clarify -- you said the license was the same, but you
> >> 
> >> didn't
> >> 
> >> > say what that license actually was. What license is your code available
> >> > under?
> >> 
> >> GPL-3+ [1]
> >> 
> >> BTW, I think if a Debian package is published the requirement to sign
> >> anything to get the source code is useless since interested parties can
> >> easily download the Debian source package.
> >> 
> >> This is for instance true for the latest source in Git which just has a
> >> compile bug which we desperately try to fix to finalise the Qt4
> >> removal[2].
> >> 
> >> Kind regards
> >> 
> >>   Andreas.
> >> 
> >> [1]
> >> https://salsa.debian.org/med-team/freemedforms-project/blob/master/COPYIN
> >> G.txt [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874880#104
> >> 
> >> > On Fri, Jan 10, 2020, 07:18 Eric Maeker  wrote:
> >> > > Hi,
> >> > > 
> >> > > For now, our NPO is too poor to engage in consulting or to pay
> >> 
> >> external
> >> 
> >> > > developments and we awfully miss time to manage all aspects of a
> >> 
> >> widely
> >> 
> >> > > collaborative project.
> >> > > Sounds like we are travelling to "contrib" or "non-free" package ? Or
> >> 
> >> may
> >> 
> >> > > be "non-debian" ?
> >> > > 
> >> > > Belle journée
> >> > > Cordialement
> >> > > 
> >> > > 
> >> > >  *Dr Maeker Éric*
> >> > > 
> >> > > *Gériatre, psychogériatre*
> >> > > eric.mae...@gmail.com
> >> > > Twitter  @DrMaeker 
> >> > > RPPS 10002307964
> >> > > 
> >> > > maeker.fr  Site personnel
> >> > > empathies.fr  Association Emp@thies
> >> > > freemedforms.com  Logiciel médical
> >> > > 
> >> > > La gériatrie, c'est la médecine pour les pères et les mères Noël
> >> > > 
> >> > > Le ven. 10 janv. 2020 à 03:03, Paul Wise  a écrit :
> >> > >> On Thu, Jan 9, 2020 at 8:00 PM Eric Maeker wrote:
> >> > >> > Free Source code is provided to any demander approved by the NPO,
> >> 
> >> code
> >> 
> >> > >> licence is still the same.
> >> > >> 
> >> > >> I don't like this, people seeking source code should not have to get
> >> > >> approval first. That said, I note that the source code is availabl

Re: FreeMedForms information

[Sebastian Hilbert]

Hi everyone,

Good to have both sides of the story. As always if all license issues are 
taken care of a fork is nothing bad.

owncloud/freecloud
OpenOffice/LibreOffice
freemedforms/freehealth

That is life.

Try to sort out any issues for the good of OpenSource.

Best wishes,
Sebastian

Am Mittwoch, 17. August 2016, 08:04:44 CEST schrieb Jérôme Pinguet:
> On 08/17/2016 12:37 AM, Eric Maeker wrote:
> > Hi everyone,
> > 
> > Firstly, excuse me for beeing so quiet these past few months.
> > 
> > I wanted to inform you that the FreeMedForms project is still alive
> > and will release soon a 1.0 version after one year of testing and
> > debugging.
> > 
> > The project has just been forked by Jérôme Pinguet.
> 
> Yes I did. I forked a GPLv3 software. I also maintained, debugged,
> upgraded and added new features to the code by myself for the last 14
> months, without any help from you or anyone else. Also, don't forget to
> give due credit for the one year of debugging and testing. :)
> 
> > The code and wiki are actually reproduced on one other website (a
> > copy/paste effort).
> 
> Don't forget to mention who set up and administered the Debian VPS, who
> installed, upgraded, and maintained Apache 2, TLS certificates, Doxygen,
> phpBB and Dokuwiki and who wrote 90% of the contributions to the wiki
> for the past two years. The license of the wiki (GFDL) allows me to copy it.
> > As he tells me, he wanted to have his own soft for his commercial
> > activities and that he will ignore open source users comments and
> > wishes...
> 
> You are lying. You are spreading lies all over the Internet because you
> cannot accept that someone forked your free and open source project...
> this is getting embarrassing.
> 
> > The FreeMedForms community will not support this fork and some members
> > of the community asked me to bannish Jérôme Pinguet.
> 
> I don't want to be part of your "community" anymore. I quit. That's
> precisely why I forked FreeMedForms.
> 
> > Nothing is done yet. All his access to the community servers, wiki,
> > forum, repositories are currently removed. I think he stole private
> > data too.
> 
> You are throwing very serious accusations in public. Forking a GPL
> software is legal, slander is not. Please get some rest (and maybe some
> help) and think twice before going on with this useless smear campaign.
> It is doing harm to both of us.
> 
> > There is a threat, he will probably not respect the GPL license terms.
> 
> You are probably having a meltdown and I feel sorry for you...
> 
> I have no problem with the GPLv3 license terms. I have no problem with
> the fact that you wrote 80% of the code. I have no problem with keeping
> your copyright notice untouched in every file of the fork forever. All
> the code I am writing, non profit and for profit, is free and open
> source and published on public repositories... what about yours? If you
> ever find more than 12 lines of code that I wrote and that are not free
> software and publicly accessible on the web, I will offer you your
> weight in bananas. I am a hardcore free software activist. I love
> freedom. I love forking and I would love being forked. I love sharing.
> What about you?
> 
> > Open source can lead to such a situation, I hope we will find the best
> > way to figure this.
> 
> True. Open source can lead to people exercising their rights as free
> software users and developers. Sit back, relax and read the definitions
> of the four freedoms again. The best way to figure this out is to ask
> yourself why you end up being alone in your open source community
> despite being an excellent coder, but the Debian Med mailing list is NOT
> the right place for introspection. I wish we could talk about this on
> FreeMedForms' mailing lists but you excluded me after sending several
> similar messages...
> 
> > For sure, the FreeMedForms project is still alive and will pursue its
> > efforts !
> 
> I am sorry for this off topic message but I couldn't let this slanderous
> email unanswered.
> 
> Eric, I think you should stop this act, you are only making a fool of
> yourself.
> 
> I forked your free and open source project, get over it.
> 
> > Freely,
> > Éric
> > https://www.maeker.fr/
> > https://www.freemedforms.com/
> 
> Jérôme Pinguet
> https://freehealth.io
> https://freemedsoft.com
> https://github.com/FreeHealth/freehealth

Re: Open-source MRI hardware initiative project

[Sebastian Hilbert]

Hi,

I am a clinical with a special interest in cardiac MRI and part time community 
manager (more or less) for GNUmed.

Am Saturday 09 April 2016, 16:19:35 schrieb Broche, Lionel:
> Hello Debian-Med team,
> 
> I am a researcher in MRI hardware at the University of Aberdeen,
> Scotland. I am currently working on the development of a completely new
> type of MRI system (see ffc-mri.org), but I would like to avoid the
> traditional route of commercialisation as I see many problems with it.
> Instead, I have been thinking for a while of preparing an initiative for
> the development of open-source hardware in MRI.
> 

If your primary goal is to facilitate research then I can see a point in 
trying an open source model for advancing the technology. If you ever want to 
see this installed in a hospital you will have to provide this through some 
sort of company. 

> The aim of this initiative would be, in a first stage, to pool the
> technical solutions already in the public domain together so as to help
> small research labs like mine and, in a second stage, to create a rally
> point for these labs to share knowledge, resources and to organise
> collective work. 

Your field of interest is pretty distinct and I would envision you pretty much 
know everyone else working on similar technology. It should be a fairly small 
community. I guess everyone who is doing research on this is trying to get 
visibility through peer-reviews publications or conference posters.

> If this proves successful, it may expand into a
> complete open source MRI hardware platform but that would be in the far
> future. I already approached several research groups who expressed their
> enthusiasm about this idea so there would be several academic
> participants to start with (at least 3, probably 5 to 8), and some of
> them are already willing to provide some designs.
> 

That is what I had in mind when I wrote the above statements.

> I would like to get some advices from the Debian Med community regarding
> several aspects:
> - What solution would you think is the most appropriate to organise a
> community portal? I do not have any IT help from my University on this
> project but I am willing to put a bit of my own money to get a server
> somewhere if necessary. Bear in mind that I have little training on how
> to maintain a website, though I can take some time to learn.

I guess you would start with data collection. A Wiki such as Foswiki should 
work for that. It is good for gathering content and caters for user 
authentication. Besides textual content it will be fine to host images and 
links to video material. No big server needed.

> - I know there is an active part of Debian Med that works on MRI
> software (and make great things, actually!), would any of them be
> interested in this initiative? 

As Andreas has said before there is a difference between Debian med (pretty 
much the people who package existing software) and Debian med users who are 
sometimes the same people that write software.

Some of these people are subscribed to the Debian med mailing list and are 
reading your messages.

See http://journal.frontiersin.org/article/10.3389/fninf.2012.00022/full for 
people who might have interest in your research.

> If yes, what would you expect from it, or
> what would you be willing to provide at this stage? 

Reaching potential users of your research could give you the right input to 
focus. Where do you see the immediate value of your research for people 
writing MRI related software. IMHO most software is about analyzing images 
acquired by existing MRI devices. How would your technology help people reach 
the clinical goal which is the reason for analyzing images ?

> Also, would you have
> some recommendations so that open-sourced MRI hardware would easily
> interface with the already existing open-source software?

I am afraid I don't fully understand what you mean. The people wrinting MRI 
image/data analysis (in broad terms) software pretty much rely on you giving 
them Dicom data. If you are referring to people who actually produce software 
that interfaces with the MRI scanner itself I am not even sure there is any of 
them on this list ( I hope I am wrong). This is usually the domain of the 
scanner vendors.

> - Would you have any suggestions regarding the conduct of such a
> project? I have no experience in the management of open source projects
> and I am actively looking for documentation about it.

Don't take the scientific approach on this :-) Set up a website ( e.g. WIKI) 
and invite people in your domain to contribute to it. What helps tremendously 
is to organize a so called sprint. A gathering of like-minded people to 
discuss your project and work on it in a friendly and non-rigid setting. This 
is different from your usual conference where there is mostly talk without 
much practical work.

> In particular, how
> can I organise this project so as to avoid bottlenecks in the future?

Worry about bottl

Re: ginkgocadx ...

[Sebastian Hilbert]

Am Thursday 28 January 2016, 21:03:47 schrieb Andreas Tille:
> On Thu, Jan 28, 2016 at 08:54:50PM +0100, Gert Wollny wrote:
> > I didn't upload a new version, because I have no rights,
> 
> I felt competent to fix at least this. ;-)
> 
> > but also
> > because it would be best if this test of functionality would be done
> > first.
> 
> Uploading to experimental might be an option.  I would assume Karsten
> is keen on testing your work.

I am not sure where Ginkgocadx is headed. Latest release seems to be a bit 
dated. There used to be a forum but I cannot find it anymore. There was a Pro 
version which is gone as well. Will test the packages asap.

Sebastian

Re: understanding DICOM workflow

[Sebastian Hilbert]

Am Wednesday 13 January 2016, 09:22:49 schrieb Sébastien Jodogne:
> Hello Sebastian,
> 
> I write you as the author of Orthanc [1] that you mentioned in your
> question.
> > > What I would like to do: [typical imaging workflow]
> > 
Just to let you know. GNUmed [1] makes extensive use of the Orthanc REST API 
to provide some nice feature for the GNUmed EMR target at general practioner's 
offices.

1 www.gnumed.de 

Regards,
Sebastian

question for VTK experts

[Sebastian Hilbert]

Hi,

I wonder if there is anyone on this list who has experience with VTK.

I have a stl file which get produced by a medical software. I need to convert 
this to another formal which is very similar to the vtk ascii format with 
polygonal dataset (format specification available).

The target format is like this:

 

  

   32.4603  6.0825  -40.3249 
   13.9858  7.9016  -41.0501 
   16.6287  7.6514  -40.4356 
   30.7806  7.9503  -41.1414  


   0.220882  -0.586701  -0.779098 
   -0.082953  -0.169572  -0.982021 
   0.393210  -0.647443  -0.652842 
   -0.106461  -0.248735  -0.962703  


  3 40 8
  17 10 13
  41 13 42
  4 36 43
  
  



   



What would be the best way to go about converting stl to Ensite dif ?

I have a sample target file and converted it to stl and vtk with a tool called 
3D object converter (http://3doc.i3dconverter.com/formats.html) which seems to 
be the only tool able to load Einsite dif files. 

Looking at the vtk file the polygons are different from the ones in the xml 
(dif) file. Looking at the stl file (ascii) I can see some vertex lines that 
match a line in the vertices section of the xml (dif) file but there are a lot 
more vertex lines in the stl file then there are in the xml (dif file).

I would prefer to use python if that is an option.

Any help is appreciated.

Sebastian

Re: DebianMed Sprint network issue

[Sebastian Hilbert]

Am Donnerstag, 11. Dezember 2014, 17:33:44 schrieb Karsten Hilbert:
> On Thu, Dec 11, 2014 at 04:09:34PM +0100, Andreas Tille wrote:
> > > I just talked with the hotel and they still have wifi access issues
> > > (though
> > > it was supposed to be solved). So it is almost plain sure that wifi
> > > won't
> > > be accessible.
> > :
> > :-(
> > 
> > No Wifi or not even internet (via LAN) ?
> 
> Since the (try to) provide Wifi access on their premises they
> "must" have some other means to get connectivity into their
> hotel in the first place.
> 
> Might it be possible to persuade them to let you guys plug in
> your own wlan repeater or even route a very long LAN cable
> from their inhouse hub to your switch in the conference room ?
>

If it helps I can send you a pair of PowerLAN adapters.

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3564844.o5PWxBbd7s@linux.local

Re: Preventing disease ebola virus.

[Sebastian Hilbert]

Hi,

Am Mittwoch, 17. September 2014, 16:45:50 schrieb camara:
> 
> So, people who may be infected with the virus are informed and are advised
> to go to a center Ebola. Health services can be connected to the
> application and have real-time information on risk areas. They may decide
> to open a treatment center in the area or nearby
>

The idea is clear. I cannot believe there is no such application yet.
 
> The application contain three parts:
> 
> 1. The server :
> 
> Hosted and centralizes all information collected temperatures. Analyzes the
> temperature and detects if there is a risk or not for a person. Represents
> positive cases on the map
> 

A prototype for this can be coded in a matter of days by an experienced web 
developer. I wonder Openstreetmap has sufficient data for this.

> 2.Terminals with IR thermometer  :
> 
> Tablet or Rasbery that is connected to an IR thermometer. It detects the
> temperature and sends it to the server via SMS. He received the diagnosis
> result via SMS or Internet.
> 

I assume the temperature readings will be collected in the field ? or in a 
hospital ? Is the application that would be running on the rasberry or tablet 
already available ?


> 3 Monitoring:
> It is any terminals (PC, laptop, smartphone, tablet ...). It oversees
> Results and declence an alarm if the positive cases.
> 

I am not aware of any application that does what you are after. However given 
some ressources I am sure a prototype can be coded in a matter of days.

On a side note. A few years back we had a prototype in GNUmed where an older 
Nokia phone received an SMS (for weight and blood pressure) and a software 
listening on a connected computer put this information into the patient 
record.

Today I would even evaluate a smartphone with GPS. An app would get the GPS 
position, fill a template SMS (manually entered temperature) and send the SMS

I admit I have not thought through how to power the "smartphone" in the field. 
I guess attaching the charger everyday is not an option.

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3014211.2Z2Kd1qQ6P@linux.local

Re: Help needed, really very simple help - you do not need to code, really

[Sebastian Hilbert]

Am Mittwoch, 30. Juli 2014, 09:57:42 schrieb Andreas Tille:
> Hi folks,
> 
> I admit that I'm a bit frustrated that not only technical work is on my
> shoulders but that I also need to care for boring licensing issues
> without strong support of the Debian Med community.  As you might have
> noticed (???) I'm continuosely trying to dispute the phylip license with
> upstream.  While the upstream author has even agreed to use a free
> license he just needs to convince his administration that this makes
> sense.  So please, pretty please, give me a chance to not be this "only
> one crazy Debian developer" when doing this discussion and sign this
> petition:
> 
>https://wiki.debian.org/DebianMed/Meeting/Southport2012/ePetition_Phylip
> 
> The background is that we can not only free one single package but also
> four dependencies and it really simplifies our work when dealing only
> with code in main.  Non-free always causes trouble in several ways and
> you could really help here with very low effort.
> 
> Thank you
> 
> Andreas.

You can put my name on the petition.

Regards,
SH

Re: DCM4CHE -- could someone update on the status?

[Sebastian Hilbert]

FYI

https://plus.google.com/105229849458089370948/posts/cxbGEUNuSvF


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2910410.2puMITp9uY@linux.local

Re: mobilECG support

[Sebastian Hilbert]

Am Montag, 14. Oktober 2013, 11:23:01 schrieb Karsten Hilbert:
> On Sat, Oct 12, 2013 at 11:20:45PM +0200, Peter Isza wrote:
> > If this is the case, then I will consider making the whole software open
> > source.
> 
> That would be very desirable but may not currently
> be possible in combination with certification.
>

The software on the device which would be firmware need not but can be open 
source. I assume he is talking about viewers or other end-user software.

Firmware can be open sourced as it is the case with many routers. Certfication 
can be obtained for any specific version and revision of the firmware.

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2514510.xcy0ndy...@thinkpad-wlan.fritz.box

Re: mobilECG support

[Sebastian Hilbert]

Am Samstag, 12. Oktober 2013, 23:20:45 schrieb Peter Isza:
> Hi Andreas,
> 
> Thanks for the quick response.
> 
> If this is the case, then I will consider making the whole software open
> source.
>

That would make it much easier to integrate with e.g. GNUmed but the API you 
are planning on is a very good start.

Regards,
Sebastian
 
> Regards,
> Peter
> 
> 
> 2013/10/12 Andreas Tille 
> 
> > Hi Peter,
> > 
> > thanks for your interest into Debian Med.
> > 
> > On Sat, Oct 12, 2013 at 07:23:10PM +0200, Peter Isza wrote:
> > > Hi all,
> > > 
> > > I've been working on this project for 8 months now:
> > > http://igg.me/at/mobilecg. I would like to make it work out of the box
> > 
> > with
> > 
> > > as many operating systems as possible.
> > > 
> > > The device is a USB HID device, it doesn't require any special drivers
> > > or
> > > kernel settings. The software itself is not open source, but the API
> > > will
> > > be open.
> > > 
> > > Would it be possible for Debian Med to support my device?
> > 
> > Any DFSG Free Software could be supported but if you want to speed up
> > the packaging of your software for Debian it might be advisable to
> > create packages on your own and ask for sponsering.  We (as in Debian
> > Med team) have some good tradition of teaching newcomers how to create
> > packages[1] and we would really like to support your attempt but if you
> > just rely that we will do the packaging work and we put it on our
> > (longish) todo list we can not make sure that we will match your timing
> > expectations (we have quite a long todo list ...)
> > 
> > Kind regards
> > 
> >Andreas.
> > 
> > [1] https://wiki.debian.org/DebianMed/MoM
> > 
> > --
> > http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1399656.E2oSWq2Jem@linux.local

Re: Searching for (medical) Qt application to be packaged

[Sebastian Hilbert]

Hi,

slicer 3D or now known as slicer 4 might benefit from some update work.

Sebastian

Am Mittwoch, 11. September 2013, 14:25:42 schrieb Andreas Tille:
> Hi Eric,
> 
> next try for a C++/Qt app:
> 
>http://bugs.debian.org/580247
> 
> Please coordinate with the people who just did some work on it.
> 
> Kind regards
> 
>   Andreas.
> 
> On Sun, Sep 08, 2013 at 08:11:20PM +0200, Eric Maeker wrote:
> > Hi Andreas,
> > 
> > Ok, look like:
> > - java coded ;)
> > - and source code not available from here:
> > http://www.thera-pi.org/html/downloads___links.php
> > 
> > Any idea ?
> > 
> > Eric
> > 
> > Le 8 sept. 2013 à 17:55, Andreas Tille a écrit :
> > > Hi Eric,
> > > 
> > > cool if you would like to spend some time on packaging.  I'm not fully
> > > sure but if I'm not miss leaded this
> > > 
> > >   http://www.thera-pi.org/
> > > 
> > > is C++/Qt and also might fit your field of interest.  If not I might
> > > dive
> > > again into our todo list.
> > > 
> > > Kind regards
> > > 
> > >   Andreas.
> > > 
> > > On Fri, Sep 06, 2013 at 03:34:47PM +0200, Eric Maeker wrote:
> > >> Hi,
> > >> 
> > >> I've got some free time to spend on a new package. If you know an open
> > >> source C++/Qt app in the medical field that needs some help to achieve
> > >> a debian packaging, you can send me an email.
> > >> 
> > >> Thanks
> > >> Eric, freemedforms.com
> > 
> > -
> > Eric Maeker, MD (Fr)
> > http://www.freemedforms.com : Suite logicielle médicale open source
> > http://asso.freemedforms.com : Association 1901 des utilisateurs de la
> > suite FreeMedForms http://wiki.debian.org/DebianMed : Debian Med est une
> > distribution Debian orientée médecine http://www.ericmaeker.fr : site
> > personnel

Re: Searching for (medical) Qt application to be packaged

[Sebastian Hilbert]

It is coded in Java.

Sebastian

Am Sonntag, 8. September 2013, 20:11:20 schrieb Eric Maeker:
> Hi Andreas,
> 
> Ok, look like:
> - java coded ;)
> - and source code not available from here:
> http://www.thera-pi.org/html/downloads___links.php
> 
> Any idea ?
> 
> Eric
> 
> Le 8 sept. 2013 à 17:55, Andreas Tille a écrit :
> > Hi Eric,
> > 
> > cool if you would like to spend some time on packaging.  I'm not fully
> > sure but if I'm not miss leaded this
> > 
> >   http://www.thera-pi.org/
> > 
> > is C++/Qt and also might fit your field of interest.  If not I might dive
> > again into our todo list.
> > 
> > Kind regards
> > 
> >   Andreas.
> > 
> > On Fri, Sep 06, 2013 at 03:34:47PM +0200, Eric Maeker wrote:
> >> Hi,
> >> 
> >> I've got some free time to spend on a new package. If you know an open
> >> source C++/Qt app in the medical field that needs some help to achieve a
> >> debian packaging, you can send me an email.
> >> 
> >> Thanks
> >> Eric, freemedforms.com
> 
> -
> Eric Maeker, MD (Fr)
> http://www.freemedforms.com : Suite logicielle médicale open source
> http://asso.freemedforms.com : Association 1901 des utilisateurs de la suite
> FreeMedForms http://wiki.debian.org/DebianMed : Debian Med est une
> distribution Debian orientée médecine http://www.ericmaeker.fr : site
> personnel



signature.asc
Description: This is a digitally signed message part.

Re: Ginkgo-CADx compilation problem form Debian package

[Sebastian Hilbert]

Am Donnerstag, 11. April 2013, 10:45:33 schrieb Mathieu Malaterre:
> I would use the latest package of dcmtk. It will pull in the missing
> shared libs.
>

Would you consider 3.6.0-11 sufficient ? If not I need to provide 3.6.0-12 
through the GNUmed PPA

precise (science): OFFIS DICOM toolkit command line utilities [universe] 
3.6.0-9: amd64 i386 
quantal (science): OFFIS DICOM toolkit command line utilities [universe] 
3.6.0-11build1: amd64 i386 
raring (science): OFFIS DICOM toolkit command line utilities [universe] 
3.6.0-12: amd64 i386 
 
http://packages.ubuntu.com/search?keywords=dcmtk

Regards,
Sebastian

Re: Ginkgo-CADx compilation problem form Debian package

[Sebastian Hilbert]

Am Donnerstag, 11. April 2013, 10:45:33 schrieb Mathieu Malaterre:
> I would use the latest package of dcmtk. It will pull in the missing
> shared libs.
> 

It might have to do with this bug

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677721

Sebastian

Ginkgo-CADx compilation problem form Debian package

[Sebastian Hilbert]

Hi,

I saw that Ginkgo-CADx is packaged in experimental. I tried to compile it for 
Ubuntu 12.10 locally (dget -xu, debuild -B) and get the following output. I 
guess there are some different versions for the dependencies. Any pointer 
(what to research) would be appreciated.

libdcmtk2:
  Installed: 3.6.0-11build1
  Candidate: 3.6.0-11build1
  Version table:
 *** 3.6.0-11build1 0
500 http://archive.ubuntu.com/ubuntu/ quantal/universe i386 Packages
100 /var/lib/dpkg/status

/usr/bin/c++-fPIC -pthread -g -O2 -fstack-protector --param=ssp-buffer-
size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2   -Wl,-Bsymbolic-
functions -Wl,-z,relro -Wl,--as-needed CMakeFiles/ginkgocadx.dir/main.cpp.o  -
o ginkgocadx -rdynamic -L/home/basti/Sources/ubuntu-packages/ginkgo-
cadx/ginkgocadx-3.2.0.634.25/src/../lib/Linux-x86/libcurl-7.28.1/lib/release -
L/usr/lib/InsightToolkit ../cadxcore/libCADxCore.a 
../visualizator/libvisualizator.a -ldcmdata -ldcmimage -ldcmimgle -ldcmjpeg -
ldcmnet -ldcmpstat -ldcmqrdb -ldcmsr -ldcmtls -lijg12 -lijg16 -lijg8 -lofstd -
loflog -ldcmdsig -ldcmtls -lwrap ../cadxcore/libCADxCore.a -lcurl -ldcmdata -
ldcmimage -ldcmimgle -ldcmjpeg -ldcmnet -ldcmpstat -ldcmqrdb -ldcmsr -ldcmtls 
-lijg12 -lijg16 -lijg8 -lofstd -lsqlite3 -lfreetype -lglib-2.0 -lgobject-2.0 -
lgdk_pixbuf-2.0 -lgdk-x11-2.0 -lgtk-x11-2.0 -lcairo -lpango-1.0 -latk-1.0 -
lssl -lcrypto -L/usr/lib/i386-linux-gnu -pthread -lwx_gtk2u_core-2.8 -
lwx_baseu-2.8 -lwx_gtk2u_gl-2.8 -lwx_baseu_net-2.8 -lwx_baseu_xml-2.8 -
lwx_gtk2u_aui-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_richtext-2.8 -
lwx_gtk2u_xrc-2.8 /usr/lib/libvtkGenericFiltering.so.5.8.0 
/usr/lib/libvtkGeovis.so.5.8.0 /usr/lib/libvtkCharts.so.5.8.0 
/usr/lib/libvtkViews.so.5.8.0 /usr/lib/libvtkInfovis.so.5.8.0 
/usr/lib/libvtkWidgets.so.5.8.0 /usr/lib/libvtkVolumeRendering.so.5.8.0 
/usr/lib/libvtkHybrid.so.5.8.0 /usr/lib/libvtkParallel.so.5.8.0 
/usr/lib/libvtkRendering.so.5.8.0 /usr/lib/libvtkImaging.so.5.8.0 
/usr/lib/libvtkGraphics.so.5.8.0 /usr/lib/libvtkIO.so.5.8.0 
/usr/lib/libvtkFiltering.so.5.8.0 /usr/lib/libvtkCommon.so.5.8.0 
/usr/lib/libvtksys.so.5.8.0 -lITKAlgorithms -lITKNumerics -lfftw3 -
lfftw3_threads -lfftw3f -lfftw3f_threads -lITKStatistics -litkNetlibSlatec -
lITKFEM -lITKBasicFilters -lITKIO -lITKNrrdIO -lgdcmMSFF -litkjpeg8 -lpng -
ltiff -lITKSpatialObject -lITKMetaIO -lITKDICOMParser -lITKEXPAT -lITKniftiio 
-lITKznz -lz -lITKTransformIOReview -lITKQuadEdgeMesh -lITKCommon -
litkvnl_inst -litkvnl_algo -litkv3p_netlib -litkvnl -litkvcl -litkv3p_lsqr -lm 
-litksys -lpthread -lm -ldl -lGL -lxml2 -lwrap -Wl,-
rpath,/home/basti/Sources/ubuntu-packages/ginkgo-
cadx/ginkgocadx-3.2.0.634.25/src/../lib/Linux-
x86/libcurl-7.28.1/lib/release:/usr/lib/InsightToolkit:/usr/lib/openmpi/lib: -
Wl,-rpath-link,/usr/lib/openmpi/lib 
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlFree'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlSetGenericErrorFunc'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlNodeGetContent'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlBufferContent'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlSchemaNewValidCtxt'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `__xmlGetWarningsDefaultValue'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlSchemaSetValidErrors'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlSearchNsByHref'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `__xmlGenericErrorContext'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlFindCharEncodingHandler'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlSchemaSetParserErrors'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlFreeDoc'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlSchemaFree'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlSchemaParse'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlParseFile'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlSchemaFreeValidCtxt'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlIsBlankNode'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlLineNumbersDefault'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlDocGetRootElement'
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libdcmsr.so: undefined 
reference to `xmlBufferFree'
/usr/lib/gcc/i686-linux-gnu/4.7/../../..

Re: Aw: Re: Re: new upstream release for GNUmed

[Sebastian Hilbert]

On Monday, April 01, 2013 04:56:01 PM Karsten Hilbert wrote:
> > >> Preconfiguring packages .
> > >> trying to overwrite '/usr/share/man/man1/gm-remove_person.1.gz', which
> > >> is
> > >> also in package gnumed-client 1.3.1-1quantal
> > > 
> > > I found out it is shipped in both tarballs , gnumed-client and
> > > gnumed-server. I guess dpkg does not like this.
> > 
> >  
> > 
> > > The file could either be overwritten
> > 
> > Debian won't do that.
> > 
> > > or it needs to be removed from one of the tarballs I guess.
> > 
> >  
> > Certainly not from the tarballs but rather from one of the packages.
> > 
> > Or, rather, moved to package gnumed-doc.
> 
>  
> 
> > What do you prefer ?
> 
> Well, as far as gm-remove_person.1.gz goes -doc would be just fine. That
> doesn't solve the question of what to do with /usr/bin/gm-remove_person
> itself, though.
> 
> There's two "proper" answers to that:
> 
> 1) Anything not -server is -client, so if people want to be able to
> access the GNUmed database (say, removing a person) w/o resorting to
> PostgreSQL tools (psql) they would need to install some sort of -client
> package. However, the client pulls in LOADS of LaTeX which just isn't
> fair on server machines just because the admin wants a local
> gm-remove_person.
> 
> 2) Create a -tools which would include gm-remove_person(.1.gz). We've got
> precious few other things that would go in there, however, so whether that's
> worth the effort ...
> 

It is tools then. Please spell out what you would like to see in there and I 
will give it a shot.

Sebastian

> Karsten

Re: Aw: Re: new upstream release for GNUmed

[Sebastian Hilbert]

On Monday, April 01, 2013 04:30:16 PM Karsten Hilbert wrote:
> >> Preconfiguring packages .
> >> trying to overwrite '/usr/share/man/man1/gm-remove_person.1.gz', which is
> >> also in package gnumed-client 1.3.1-1quantal
> 
>  
> 
> > I found out it is shipped in both tarballs , gnumed-client and
> > gnumed-server. I guess dpkg does not like this.
>  
> 
> > The file could either be overwritten
> 
> Debian won't do that.
> 
> > or it needs to be removed from one of the tarballs I guess.
> 
>  
> Certainly not from the tarballs but rather from one of the packages.
> 
> Or, rather, moved to package gnumed-doc.
> 

What do you prefer ?

Sebastian

Re: new upstream release for GNUmed

[Sebastian Hilbert]

On Friday, March 29, 2013 08:53:17 PM Sebastian Hilbert wrote:
> Hi,
> 
> I have just hit an error.
> 
> Preconfiguring packages ...
> Selecting previously unselected package gnumed-server.
> (Reading database ... 726724 files and directories currently installed.)
> Unpacking gnumed-server (from .../gnumed-server_18.1-1quantal1_all.deb) ...
> dpkg: error processing /var/cache/apt/archives/gnumed-
> server_18.1-1quantal1_all.deb (--unpack):
>  trying to overwrite '/usr/share/man/man1/gm-remove_person.1.gz', which is
> also in package gnumed-client 1.3.1-1quantal2
> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> postrm called with unknown argument `abort-install'
> dpkg: error while cleaning up:
>  subprocess new post-removal script returned error exit status 1
> 
> Where do I have to look for the source of the problem ?
> 

I found out it is shipped in both tarballs , gnumed-client and gnumed-server. 
I guess dpkg does not like this.

The file could either be overwritten or it needs to be removed from one of the 
tarballs I guess.

Sebastian

Re: new upstream release for GNUmed

[Sebastian Hilbert]

Hi,

I have just hit an error. 

Preconfiguring packages ...
Selecting previously unselected package gnumed-server.
(Reading database ... 726724 files and directories currently installed.)
Unpacking gnumed-server (from .../gnumed-server_18.1-1quantal1_all.deb) ...
dpkg: error processing /var/cache/apt/archives/gnumed-
server_18.1-1quantal1_all.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/gm-remove_person.1.gz', which is 
also in package gnumed-client 1.3.1-1quantal2
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
postrm called with unknown argument `abort-install'
dpkg: error while cleaning up:
 subprocess new post-removal script returned error exit status 1

Where do I have to look for the source of the problem ?

Sebastian

Re: new upstream release for GNUmed

[Sebastian Hilbert]

On Wednesday, March 27, 2013 01:23:06 PM Andreas Tille wrote:
> Hi Sebastian,
> 
> On Wed, Mar 27, 2013 at 12:47:01PM +0100, Sebastian Hilbert wrote:
> > Is it safe to check these changes in or do you want to review them ?
> 
> Just be bold and commit your changes.  There is no chance to break
> anything from your side.  If something will not work on my side I will
> not upload and will rather discuss / fix it.
> 
Done.

However Karsten has indicated that he would like to see GNUmed delayed in 
experimental.

I have uploaded to Ubuntu independently so there is no rush.

Sebastian

Re: new upstream release for GNUmed

[Sebastian Hilbert]

Hi all,

I have checked out trunk and made some changes. I have built with debuild -S 
and it went through.

Is it safe to check these changes in or do you want to review them ?

Regards,
Sebastian

Re: new upstream release for GNUmed

[Sebastian Hilbert]

On Wednesday, March 27, 2013 12:12:14 PM Karsten Hilbert wrote:
> On Wed, Mar 27, 2013 at 10:56:42AM +0100, Hilbert, Sebastian wrote:
> > I would start with testing 1.3.x in experimental. 1.2.x should move to
> > unstable and later to testing.
> 
> Both together is not possible unless we want to increase
> problems SHOULD there happen to be an RC bug in the 1.1
> branch.
> 
> IMO we should wait for a few more 1.3 releases until
> reconsidering putting 1.3 into experimental.
> 
I guess we can safely ignore 1.1.x if that helps.

I don't have a problem with waiting. I just feel that 1.1.x causes more 
trouble then benefit. So we should consider getting 1.2.x into backports.

Sebastian

Re: new upstream release for GNUmed

[Sebastian Hilbert]

Hi Andreas,

Let's see what Karsten has to say about this. I guess many Debian users run a 
combination of stable and testing. So from my point of view it might make 
sense to put 1.2.9 into (future) testing and 1.3.x into unstable.

1.1.x is effectively discontinued. I doubt that anyone relies on it anymore. 
Once freeze is over we could think about moving 1.2.x into backports.

I would start with testing 1.3.x in experimental. 1.2.x should move to 
unstable and later to testing.

For Ubuntu users it makes no difference if 1.3 is in unstable or experimental. 
Once a Debian package is there it is provided via the GNUmed PPA. I have long 
given up trying to catch Ubuntu releases.

Sebastian

new upstream release for GNUmed

[Sebastian Hilbert]

Hi,

I am starting to look at the docs for updating the gnumed packages in light of 
a new major release.

I see that 1.2.9 is in experimental. I guess there could be more 1.2.x 
versions in the future.

If I got that right Debian is in freeze right now. Wheezy will be the new 
stable , right ? The 1.2.x series is the stable one but will never make it 
into Wheezy I guess. So it will go into the future testing.

Is Sid going to be turned into testing ? If so could the 1.2.x series move 
from experimental to sid ?

How can I handle this if I want to package 1.3.x in experimental ? Do I have 
to wait for Wheezy's release.

Best regards,
Sebastian Hilbert

Re: Med-E-Tel 2013 Poster

[Sebastian Hilbert]

Hi,

Please consider the following changes.

 have to be checked « by-hand » --> has instead of have, manually instead of 
by-hand

There are no automated data-mining --> There is instead of are

some does not have any (or a weak) systemic passage --> some drugs do not ...

the engine analyses --> the engine analyzes ...

GnuMED --> GNUmed

Otherwise well done. Have a good time.

Regards,
Sebastian

 

On Saturday, March 16, 2013 12:02:06 PM Eric Maeker wrote:
> Hi all,
> 
> So, we done the poster for the upcoming Med-E-Tel event - open source
> village. We'd be happy to read your comments before the poster is printed.
> 
>   http://ericmaeker.fr/FreeMedForms/medetel_2013.pdf
> 
> Thanks for your review and comments.
> 
> Eric, freemedforms.com

Re: Help: Please seek for sources of some JS files in GNUmed [Was: Bug#685351: src:gnumed-client: Missing source code for *.js files]

[Sebastian Hilbert]

Hi Andreas,

On Saturday, September 15, 2012 07:34:25 PM Andreas Tille wrote:
> On Sat, Sep 15, 2012 at 06:40:25PM +0200, Sebastian Hilbert wrote:
> > Here are the sources I think
> > 
> > http://svn.foswiki.org/trunk/JSTreeContrib/pub/System/JSTreeContrib/
> > 
> > Those files are run through some js minifier on tarball creation
> 
> This is what usually is done.
> 
> > Let me check if I can find what exactly they are doing.
> > 
> > I still think this is a non-issue. There is no missing source code. The
> > source code is in the tarball. Why is it of any importance that the
> > source in svn is different. The relevant sources are shipped in the
> > tarball.
> 
> There is some longish discussion on debian-devel list (I think in August
> archive) why this is actually important.
> 

This is not leading anywhere. Let me know which of the following options would 
waste the least amount of everyone's time.

1.) I will provide locations to the files in the foswiki svn but I will not 
check (and verify) which tool (with whatever obscure parameter) is used to get 
from the file in svn to the file in the tarball. IOW I will not dissect their 
build script.

2.) I will have Karsten provide a simple patch which will simply delete the 
offending files from our tarball so upstream is clean

3.) I can live with simply droping gnumed-doc since getting all the details 
right is taking more ressource then I am willing to allocate to this (this 
would make it easier for you as well)

I am grateful for your attempts to solve this (including checking licenses) 
but I am not willing to spend time on checking what upstream does.

Since those files are FOSS licensed we could even go as far as including them 
into the GNUmed tarball and pretend those were ours. 

Regards,
Sebastian Hilbert

> Kind regards
> 
>Andreas.


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1492510.zrmqdqk...@linux.fritz.box

Re: Help: Please seek for sources of some JS files in GNUmed [Was: Bug#685351: src:gnumed-client: Missing source code for *.js files]

[Sebastian Hilbert]

Hi,

On Monday, August 20, 2012 08:57:21 AM Andreas Tille wrote:
> Hi,
> 
> after reading the bug report twice I noticed that the problem is
> actually not comparable to the issue discussed currently on
> debian-devel@l.d.o, because the files are actually used in the
> package and not replaced.  So if you want to help Debian Med you
> can do some research and find the sources of the following files
> inside the gnumed-doc package:
> 
>   user-manual/rsrc/System/JSTreeContrib/jquery.jstree.js
>   user-manual/rsrc/System/JQueryPlugin/plugins/foswiki/jquery.foswiki.js
>   user-manual/rsrc/System/PatternSkin/pattern.js
>   user-manual/rsrc/System/JavascriptFiles/foswikiForm.js
>   user-manual/rsrc/System/JavascriptFiles/foswikiString.js
>   user-manual/rsrc/System/JavascriptFiles/foswikiPref.js
> 
> Please halpe me saving my time and doing some more technical work.
> This could be your contribution to fix a RC bug in Wheezy.
> 

Here are the sources I think

http://svn.foswiki.org/trunk/JSTreeContrib/pub/System/JSTreeContrib/

Those files are run through some js minifier on tarball creation

Let me check if I can find what exactly they are doing.

I still think this is a non-issue. There is no missing source code. The source 
code is in the tarball. Why is it of any importance that the source in svn is 
different. The relevant sources are shipped in the tarball.

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/7449308.h0cax34...@linux.fritz.box

Re: Bug#685351: Bug#685351: Help: Please seek for sources of some JS files in GNUmed [Was: Bug#685351: src:gnumed-client: Missing source code for *.js files]

[Sebastian Hilbert]

Hi

On Friday, September 07, 2012 01:21:41 PM Andreas Tille wrote:
 
> This leaves us with two options:
> 
>   1. Bother FowWiki upstream what they did really used (they must somehow
>  have these files!)
>   2. Replace the installed JS script by what we get via yui-compressor
>  from the sources above (which might most probably work as well
>  ... hopefully.
> 
> Finally there are the remaining files in
> 
>doc/user-manual/rsrc/System/JavascriptFiles/foswiki*.js
> 
> were I also failed finding the source.
> 
I will contact the Foswiki authors.

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5251214.2gmaskl...@linux.fritz.box

Re: Help: Please seek for sources of some JS files in GNUmed [Was: Bug#685351: src:gnumed-client: Missing source code for *.js files]

[Sebastian Hilbert]

Hi Andreas,

On Thursday, September 06, 2012 09:53:19 PM Andreas Tille wrote:

> Hi Sebastian,
> 
> On Mon, Aug 27, 2012 at 08:20:14PM +0200, Sebastian Hilbert wrote:
> > > after reading the bug report twice I noticed that the problem is
> > > actually not comparable to the issue discussed currently on
> > > debian-devel@l.d.o, because the files are actually used in the
> > > package and not replaced.  So if you want to help Debian Med you
> > > can do some research and find the sources of the following files
> > > 
> > > inside the gnumed-doc package:
> > >   user-manual/rsrc/System/JSTreeContrib/jquery.jstree.js
> > 
> > http://www.jstree.com/documentation
> > MIT or GPL2
> > 
> > >   user-manual/rsrc/System/JQueryPlugin/plugins/foswiki/jquery.foswiki.js
> > 
> > http://foswiki.org/Extensions/JQueryPlugin
> > GPL
> > 
> > >   user-manual/rsrc/System/PatternSkin/pattern.js
> > 
> > http://trac.foswiki.org/browser/trunk/PatternSkin/lib/Foswiki/Contrib/Patt
> > ernSkin.pm?rev=14650
> > 
> > part of PatterSkin
> > 
> > GPL
> 
> I tried to check these links.  I think it needs some clarification:
> There is no real doubt that the code is GPL.  The main problem is that
> we need to have the source code of the files that were used and which
> could be used to reproduce the compressed *.js files.  I did not found
> those very files which we could include as copy into the package.
> 
> > >   user-manual/rsrc/System/JavascriptFiles/foswikiForm.js
> > 
> > http://www.koders.com/javascript/fid7DAA754986238FA7FE093BDE7031C706AB24FB
> > E2.aspx?s=form#L6
> > 
> > Apache Version 2
> > 
> > >   user-manual/rsrc/System/JavascriptFiles/foswikiString.js
> > 
> > http://trac.foswiki.org/browser/trunk/core/pub/System/JavascriptFiles/fosw
> > ikiString_src.js
> > 
> > GPL
> > 
> > >   user-manual/rsrc/System/JavascriptFiles/foswikiPref.js
> > 
> > http://trac.foswiki.org/browser/trunk/core/pub/System/JavascriptFiles/fosw
> > ikiPref_src.js
> > 
> > GPL
> > 
> > All files stem from a default install of Foswiki
> 
> It seems these *.js files could be fetched from VCS and these are OK.
> 
> In short:  If we do not find the real source files of the part above
> we should probably remove them from the gnumed-client tarball and
> drop the gnumed-doc package (which would be a shame IMHO).
>

I was not aware those js files are somehow compressed. I was under the 
impression these files are pure source files. If not please drop the js files 
as 
the doc packge will work without them. Output will just look a bit uglier but 
I don't care. So before dropping content please consider dropping styling.

Regards,
Sebastian
 
> Kind regards
> 
>   Andreas.


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/7705403.v4zv1ch...@linux.fritz.box

Re: Help: Please seek for sources of some JS files in GNUmed [Was: Bug#685351: src:gnumed-client: Missing source code for *.js files]

[Sebastian Hilbert]

On Monday, August 20, 2012 08:57:21 AM Andreas Tille wrote:
> Hi,
> 
> after reading the bug report twice I noticed that the problem is
> actually not comparable to the issue discussed currently on
> debian-devel@l.d.o, because the files are actually used in the
> package and not replaced.  So if you want to help Debian Med you
> can do some research and find the sources of the following files
> inside the gnumed-doc package:
> 
>   user-manual/rsrc/System/JSTreeContrib/jquery.jstree.js

http://www.jstree.com/documentation
MIT or GPL2

>   user-manual/rsrc/System/JQueryPlugin/plugins/foswiki/jquery.foswiki.js

http://foswiki.org/Extensions/JQueryPlugin
GPL

>   user-manual/rsrc/System/PatternSkin/pattern.js

http://trac.foswiki.org/browser/trunk/PatternSkin/lib/Foswiki/Contrib/PatternSkin.pm?rev=14650

part of PatterSkin

GPL

>   user-manual/rsrc/System/JavascriptFiles/foswikiForm.js

http://www.koders.com/javascript/fid7DAA754986238FA7FE093BDE7031C706AB24FBE2.aspx?s=form#L6

Apache Version 2

>   user-manual/rsrc/System/JavascriptFiles/foswikiString.js

http://trac.foswiki.org/browser/trunk/core/pub/System/JavascriptFiles/foswikiString_src.js

GPL

>   user-manual/rsrc/System/JavascriptFiles/foswikiPref.js
> 

http://trac.foswiki.org/browser/trunk/core/pub/System/JavascriptFiles/foswikiPref_src.js

GPL

All files stem from a default install of Foswiki

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/12043228.i8htblr...@linux.fritz.box

Re: Packaging OpenEMR officially for Debian

[Sebastian Hilbert]

 Original-Nachricht 
> Datum: Tue, 31 Jul 2012 08:07:57 -0400
> Von: "Sam Bowen, MD" 
> An: Andreas Tille 
> CC: Debian Med Project List , Brady Miller 
> 
> Betreff: Re: Packaging OpenEMR officially for Debian

> Dear Andreas:
> 
> Good to hear from you again.  I loved the conference and was very glad 
> to meet you in person.   I discussed this with Brady Miller after my 
> return from Geneva.  One of Brady's concerns was the the ability of 
> upgrading existing OpenEMR installations using a standard Debian 
> package.  i was hoping that you would address this with him?
> 
> Sam Bowen, MD

Ho do you guys handle the upgrades? Note I assume you are talking about 
database upgrades ? IN GNUmed we just ship updated files. Actually upgrading 
the database is up to the user. They have to call a shell script (upgrade-db.sh)

Sebastian


> 
> On 07/31/2012 03:56 AM, Andreas Tille wrote:
> > Hi,
> >
> > at LSM in Geneva I was watching the talk of Sam and we had some
> > discussion afterwards about packaging OpenEMR for official Debian.  As
> > far as I can see on OpenEMR download page[1] Brady Miller has created
> > some binary package.  I used this as some inspiration to create some
> > preliminary and totally untested packaging stuff at[2].
> >
> > Brady, Sam, would you mind watching the video of my talk at LSM which I
> > linked from my talks page[3] to better understand the ideas behind
> > Debian Med and perhaps try to work together making OpenEMR an official
> > package?  This could for instance be done in some Mentoring of Month[4]
> > project.
> >
> > Kind regards
> >
> > Andreas.
> >
> > [1] http://www.oemr.org/Download_OpenEMR/
> > [2] http://svn.debian.org/wsvn/debian-med/trunk/packages/openemr/trunk/
> > [3] http://people.debian.org/~tille/talks/20120711_vista-in-debian/
> > [4] https://wiki.debian.org/DebianMed/MoM
> >
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/5017ca9d.2010...@oemr.org
> 


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120731132337.119...@gmx.net

Re: OSCAR 10.12 has been packaged

[Sebastian Hilbert]

On Sunday, July 29, 2012 09:24:24 AM Peter Hutten-Czapski wrote:

> So for the moment and the near future our poor man's debification of
> Oscar will have to do.  I am interested in getting it cleaned up so
> that it would be eligible to enter a repository, its just too much for
> me right now.
>

Fair enough. Just keep it in mind. There might be potential users out there 
(e.g. outside Canada or ourside the reach of OSP) who would benefit from having 
it in the Debian repositories. Whenever you have some time to tackle this 
(e.g. by working with experienced Debian developers) you are welcome to ask 
any questions here.

Regards,
Sebastian Hilbert

Re: OSCAR 10.12 has been packaged

[Sebastian Hilbert]

On Sunday, July 29, 2012 02:41:56 PM Karsten Hilbert wrote:
> On Sun, Jul 29, 2012 at 08:26:45AM -0400, Peter Hutten-Czapski wrote:
> > For now I release things that look like debs at sourceforge.
> 
> Which is great but it need not stay that way.
> 
> > The next hill to a more formal repository seems a bit steep right now
> 
> It is not about a repository.
> 
Getting a software packaged properly will give users a clear path towards 
installation package source, upgrade paths and so on.
Furthermore it is quality control and enables feedback through well 
established channels.

Sebastian

Re: OSCAR 10.12 has been packaged

[Sebastian Hilbert]

On Sunday, July 29, 2012 10:22:31 AM Adrian Midgley wrote:
> On 29 July 2012 08:22, Sebastian Hilbert  wrote:
> > I would love to see Oscar packaged in Debian proper.
> 
> So would I.

My mail was incomplete. I blindcopied upstream (Peter Hutten-Czaspki) to get 
this started again.

Sebastian

Re: OSCAR 10.12 has been packaged

[Sebastian Hilbert]

Reopening this thread.

Seems back in 2011 there was some effort to get Oscar into Debian.

http://new.oscarmanual.org/oscar_emr_12/developers/installation/12deb

indicates upstream is putting some more effort into packaging as deb.

Please consider picking up where the last attempt was discontinued.

I would love to see Oscar packaged in Debian proper.

Regards,
Sebastian Hilbert
GNUmed team

Re: gnumed-client 1.2.0 , needs sponsorship

[Sebastian Hilbert]

On Thursday, July 26, 2012 02:55:26 PM Andreas Tille wrote:
> Hi Sebastian,
> 
> On Thu, Jul 26, 2012 at 01:53:46PM +0200, Sebastian Hilbert wrote:
> > I was under the impression that I prepared both server and client.
> 
> No, only client was updated.  If you would confirm I just need to increase
> the version number I'll go on upload.
> 

svn indicates I worked on the control file six weeks ago. Apparently I forgot 
to update the changelog

The version for experimental would be 17.1. Diff says all I did was add myself 
to the changelog (yeah) :-)

> > However I
> > did not explicetly prepare 1.2.1 but rather 1.2.0. There are no
> > differences
> > with regards to the rules file or config files however so I guess just
> > changing the version would do it ?
> 
> Just uploaded.

With regards to 1.2.1 I just noticed that that I made a mistake in the rules 
file by forgetting to change the  to server version 17. It still 
suggests v16 for the 1.1 clients.

> 
> > I assume that when a package is built on the Debian servers the sources
> > are
> > downloaded fresh anyway from upstream ?
> 
> This assumption is wrong.  There is no such process that automatically
> fetches new upstream source.  The Debian maintainer gets a notification
> from uscan about new upstream versions and will download this, increase
> the changelog entry (a changelog entry that does not match the source
> tarball will not build) and than the package will be pushed to the
> Debian servers.  Debian servers have *never* automatically fetched any
> upstream sources and I guess this will also never happen in the future.
> 

I see.

In summary gnumed-server 17.1 can be uploaded. In one of the next bug fix 
releases suggests should be changed as noted above. Will now go in and try to 
commit a fix.

Thanks for your help.
Sebastian

Re: gnumed-client 1.2.0 , needs sponsorship

[Sebastian Hilbert]

On Thursday, July 26, 2012 01:40:02 PM Andreas Tille wrote:
> On Thu, Jul 26, 2012 at 01:07:40PM +0200, Sebastian Hilbert wrote:
> > > What do you think?
> > 
> > I assume this holds true until frozen state is changed to released state ?
> > 
> > If so uploading to experimental would be the way to go.
> 
> Fine.  I just realised that you even used experimental as target
> distribution. I'll upgrade change log entry to 1.2.1 and upload, right?
> 
> What about the server package?

I was under the impression that I prepared both server and client. However I 
did not explicetly prepare 1.2.1 but rather 1.2.0. There are no differences 
with regards to the rules file or config files however so I guess just changing 
the version would do it ?

I assume that when a package is built on the Debian servers the sources are 
downloaded fresh anyway from upstream ?

Sebastian

Re: gnumed-client 1.2.0 , needs sponsorship

[Sebastian Hilbert]

On Thursday, July 26, 2012 12:03:35 PM Andreas Tille wrote:
> Hi,
> 
> On Thu, Jul 26, 2012 at 10:58:05AM +0200, Sebastian Hilbert wrote:
> > Hi all,
> > 
> > GNumed 1.2.0 was prepared before the freeze but not uploaded to avoid
> > problems. Now that Debian is frozen is this the right time to upload to
> > unstable ?
> 
> It is correct that I was delaying the upload because of the freeze.  It
> might happen that we need to get another upgrade into testing and this
> goes only via unstable.  There are two options:
> 
>1. Upload 1.2.x to experimental
>2. Upload 1.2.x to unstable and in case of the need of
>   upgrading 1.1.x we need to push testing-proposed-updates
> 
> What do you think?
> 

I assume this holds true until frozen state is changed to released state ?

If so uploading to experimental would be the way to go.


Regards,
Sebastian

gnumed-client 1.2.0 , needs sponsorship

[Sebastian Hilbert]

Hi all,

GNumed 1.2.0 was prepared before the freeze but not uploaded to avoid 
problems. Now that Debian is frozen is this the right time to upload to 
unstable ?

Thanks,
Sebastian

Re: Free Clinic

[Sebastian Hilbert]

On Friday, July 13, 2012 02:15:15 PM Nicolas Barbier wrote:
> 2012/7/13 Chuck Peters :
> > A volunteer of our local Free Clinic asked me about migrating the
> > patient records from Microsoft Access to another sql database.  I could
> > help them setup a Debian server, but I have no experience with medical
> > records systems or migrating db's from MS Access to whatever.
> 
> (I am assuming that they use some custom-built Access-based software
> to manage their records.)
> 

I (maybe wrongly) assumed that they have data in some MS Access 
frontend/backend but might be willing to start fresh.

> The difficulty of such a migration totally depends on the source database:
> 
> * What do they store? (Does everything have a corresponding “field” in
> GNUmed?) 

It is essential to know more about the current solution.

> * How good do they want the result to be? (Is it ok to migrate a
> bunch of things in a free text form, i.e., is it good enough to just “not
> lose” the previous data?)
> 

Often we see that historical data is kept in the old app and new data is added 
to the new app. Depending on how much information can be obtained about the 
old app we might be able to assist you in transferring as much as possible.

> You probably will have to go through their database schema, identify
> the meaning of each column in detail, and make decisions regarding the
> above questions. Then you would probably write a script to read,
> convert, and inject the data into a GNUmed database.
> 

Exactly.

Sebastian

Re: Free Clinic

[Sebastian Hilbert]

On Thursday, July 12, 2012 11:44:11 PM Chuck Peters wrote:

Hi Chuck,

> A volunteer of our local Free Clinic asked me about migrating the
> patient records from Microsoft Access to another sql database.  I could
> help them setup a Debian server, but I have no experience with medical
> records systems or migrating db's from MS Access to whatever.  I know
> this description is very weak in terms of system requirements, but I am
> just trying to learn a bit before I talk to people at the clinic. I
> browsed a bit of the Debian Med site and I'm not sure where to go from
> here.  Any suggestions?


In general you have quite some options when looking at free(dom) EMR software. 
Some is packaged in Debian for easy installation and some is not.

In general there are two large requirements. One is clinical requirements and 
one is administrative requirements (billing etc.) SInce you are migrating from 
Microsoft Access I assume the clients will be running on MS Windows and they 
want you to set up a Debian server as backend.

You don't have a problem here. You can look at GNUmed, FreeMedForms, OpenEMR, 
GNU-Health and openMRS to name a few. Some have webbased client interfaces, 
some have regular clients.

Have a look at
http://medfloss.org/taxonomy/term/5

but be aware that not all software mentioned there is packaged and not even fit 
for the job.

My (biased) suggestion would be to go with GNUmed. It is very well supported 
in Debian(-med) and actively developed. Clients and Server can be run on a mix 
of Windows and Linux, Linux only or Windows only. Since I am part of upstream 
you already have a contact if things go wrong.

have a look at wiki.gnumed.de to check it out.

apt-get install gnumed-client
apt-get install gnumed-server
sudo gm-bootstrap_server

will get you started.

In case you missed it Debian-med folks are currently busy with packaging 
*Vista-EMR/EHR. But you need to decide if this is overkill for you.

Regards,
Sebastian

Re: trimming GNUmed

[Sebastian Hilbert]

On Tuesday, July 10, 2012 03:34:23 PM Gour wrote:
> On Mon, 9 Jul 2012 23:34:18 +0200
> 
> Karsten Hilbert  wrote:
> > If you tell me what you want to disable I can tell you
> > whether that's worth the effort.
> 
> I installed GNUmed on Win XP (under vbox) which seems the quickest way
> (kudos to devs for providing easy install) and didn't have much time to play
> with it, but will do.
> 
> However, when you say "...whether that's worth the effort" I might
> conclude it's, in general, not straightforward and I understand 'cause
> GNUmed is specialized application serving its own market.
> 

Have a look at the screenshots.

http://www.gnumed.de/promotion/graphics/screenshots/0.2.3/startup_all_plugins.jpg

You can disable any of those tabs at the buttom. Those are dynamically loaded 
plugins. You start GNUmed, define a workplace name, tell it which plugins are 
in that workplace and then change the config file to have GNUmed start that new 
workplace.

If you have something different in mind you need to spell it out. Some people 
have thought GNUmed code is too much for them. They have started a new project 
called clinica.

When you do this you will notice in a few years that you need that code and 
soon your code is a big as GNUmed. Forget about it. Just configure a workplace 
with as many or few plugins as you like and be done with it :-)

I guess we should move this discussion to gnumed-devel mailing list.

Sebastian

Re: Starting packaging VistA (Re: LSM in Geneva)

[Sebastian Hilbert]

On Sunday, July 08, 2012 07:04:39 PM Karsten Hilbert wrote:
> On Sun, Jul 08, 2012 at 12:07:38PM -0400, Luis Ibanez wrote:
> > We could, equally arbitrarily use version "30.0"...
> > 
> > or use the number "2012" as a year ?
> 
> This might actually be an idea given TexLive20xx
> 
Subsequent versions could be named. 2012.1, 2012.2 and so on. 

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/60992506.3x59ya8...@linux.fritz.box

gnumed-client 1.1.16

[Sebastian Hilbert]

Hi,

Please have a look at

http://release.debian.org/migration/testing.pl?package=jquery-goodies

Does this prevent gnumed-client from moving to testing ?

Regards,
Sebastian Hilbert


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5884962.xmju55c...@linux.fritz.box

GNUmed and LibreOffice

[Sebastian Hilbert]

Hi all,

On my journey to getting a problem with GNUmed and LibreOffice (pyuno) I was 
told on IRC to talk to a person named Rene Engelhard (a Debian Developer)

How would one go about this ? Ask on the Debian (which) mailing list ? Contact 
directly ?

Any help is appreciated.

Regards,
Sebastian Hilbert


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4442420.zmvilhu...@linux.fritz.box

gnumed build dependency jquery

[Sebastian Hilbert]

Hi,

Only now that I stumbled over jquery being added as build dependency did I 
understand why Andreas mourned about the javascript stuff in gnumed-doc.

>From my point of view this js stuff should not be neccessary. I will see and 
check with upstream if this can be removed so it does not have to get 
packaged.

On another issue namely linktree. Ubuntu only recently (Oneiric) started to 
package dh-linktree. Because of that GNUmed won't build on Maverick and Natty. 
Can someone enlighten me what linktree is for ?

Best regards,
Sebastian

Re: Clinica

[Sebastian Hilbert]

On Wednesday, December 21, 2011 06:55:12 PM Leonardo Robol wrote:
> On Wed, 21 Dec 2011 17:53:24 +0100
> 
> Karsten Hilbert  wrote:
> > > I will ask the other developer of clinica to join this mailing list
> > > since he may have further details on what aspects of GNUmed have made
> > > difficult the use for the doctor.
> > 
> > Yes, please, that would be really helpful.
> 
> Yes, I will report back to you as soon I have some feedback. :)
> 
> I would like to make clear that I do not have anything at all against
> GNUmed. On the contrary, I've always considered it a good software!
>

What has never been done and is easily overlooked is the fact that you can 
make a nice and easy, totally different GUI on top of GNUmed. You can make it 
look totally different and still build on top of the GNUmed middleware and 
backend.

That way you profit from updates and code fixed and all you have to do is care 
for the GUI.

The hard part when writing any software (EMR or ERP or webbrowser and whatnot) 
is the long term support. Over time users tend to demand new features. And we 
invent them again and again and again.

We hope to cooperate with you as much as possible on such things as patient 
data exchange (software to software).

Best of luck for Clinica,
Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112211941.09172.sebastian.hilb...@gmx.net

Re: Clinica

[Sebastian Hilbert]

On Wednesday, December 21, 2011 06:00:09 PM Karsten Hilbert wrote:
> On Wed, Dec 21, 2011 at 05:40:17PM +0100, Andreas Tille wrote:
> > > One of the difficult steps she found, for example, was the initial
> > > database initialization.
> > 
> > That's actually not very hard to do.  It starts with
> > 
> > apt-get install gnumed-server
> > 
> > and afterwards following the provided README.Debian.
> 
> We even provide Live Media and virtual machine images for testing.
> 
> No installation needed AT ALL.
> 
To some GNUmed might appear overengineered. It sort of is. It tries to 
implement medical workflow the way they *should* be but that more then once 
conflicts with real world workflows where doctors try to emulate paper records 
as much as possible.

So everyone has a point.

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112211815.47536.sebastian.hilb...@gmx.net

Re: Clinica

[Sebastian Hilbert]

On Wednesday, December 21, 2011 04:55:44 PM Leonardo Robol wrote:
> On Wed, 21 Dec 2011 16:05:47 +0100
> 
> Andreas Tille  wrote:
> > At least what I know about GNUmed (my insight as "just a packager no
> > user" is probably limited) this perfectly fits the GNUmed scope which is
> > also targeting basically to a single practice and explicitely not at a
> > hospital.  It might be overwhelming in functionality at first sight but
> > maintaining medical record is simply a complex topic which finally is
> > reflected in some complexity of the software.  The beginner steps into a
> > software with some degree of complexity are always hard and probably
> > needs some professional introduction.  I (again: as an outsider) can not
> > really imagine that the approach to rewrite some more simple
> > functionality is a sustainable way to make a doctor happy.  Sooner or
> > later they will ask you for more and more features and it might end up
> > in "Yet Another GNUmed" with an interface which is different because of
> > different historical roots.
> 
> My insight of GNUmed is also limited. I have tried installing it and
> playing with it some months ago (when we suggested the software to the
> user), but nothing more.
> 
> More importantly, neither me nor the other developer are doctors, so we
> basically developed clinica following as strictly as possible the
> guidelines given by the user mentioned in the previous mail.
> 
> > I would start this discussion by trying to analyse what exact features
> > of GNUmed would contradict the usage in the practice of your friend.
> 
> One of the difficult steps she found, for example, was the initial
> database initialization.
> 
> I will ask the other developer of clinica to join this mailing list since
> he may have further details on what aspects of GNUmed have made difficult
> the use for the doctor.
> 

While I hear this argument (databases fairly often) I cannot accept it :-)

For one thing she has you as experts :-)

What we as the GNUmed team seem to always dispute is that there are users who 
cannot or will not involve external help. So this boils down to not using 
postgresql or working with a preconfigured local (extra) copy of PG. This 
technically is nonesense but some users want a software which will not bother 
them with database setup. Even mysql needs to be setup so all you can use is 
sqlite I guess.

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112211811.22080.sebastian.hilb...@gmx.net

gnumed-client config file

[Sebastian Hilbert]

Hi Andreas,
I guess you have seen that one coming. 

Just converted your gnumed-client package from Debian to Ubuntu. When I 
started the client only one plugin showed up (but fortunately both a reference 
to the public and local database).

This is because the line

GNUmed Default

 is still commented.

for openSUSE I uncomment it with this patch (it is the job of the package 
maintainer).

The patch might need an update and renaming but you get the idea.

Sebastian
--- GNUmed-0.8.rc1/client/etc/gnumed/gnumed-client.conf.example   2010-01-21 22:24:01.0 +0100
+++ GNUmed-0.8.rc1/client/etc/gnumed/gnumed-client.conf.example   2010-01-21 22:24:01.0 +0100
@@ -142,7 +142,7 @@
 # to whatever you previously used, or re-comment it
 # out.
 #
-#name = GNUmed Default
+name = GNUmed Default
 #name = System fallback
 #name = Clinician
 #name = 

Re: [opensuse-medical] Calling for help for medical project. How do I create a live cd as I want it?

[Sebastian Hilbert]

On Thursday, December 15, 2011 11:48:49 AM Stathis Iosifidis (aka diamond_gr) 
wrote:
> As Andreas mentioned, it's not cross distro issue since all distros have
> different tools to create live media.
> 
I have worked on this for years now and I can tell you this. Aside from all 
tools and distributions, let alone operating systems there are some common 
issues.

1.) bootstrap stage
2.) binary stage
3.) runtime stage

No matter what tool you use you have to care about

a) getting a working system which will give you a fully functional EMR 
(uncluding running database to store data)

b) preserve any data the user puts in during runtime (after booting and 
surving reboots)

a has been done both for OpenSUSE and Debian. b is a matter of setting it up. 
There is absolutely no magic to it. Takes only like a week or so to fully 
understand the different tools and read the documentation. Then you can redo it 
whenever you like.

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112151344.14016.sebastian.hilb...@gmx.net

Creating a global "Linux Medical Team" / biomedical brand

[Sebastian Hilbert]

Hi,

Just wanted to share

http://nebc.nerc.ac.uk/tools/bio-linux/bio-linux-6.0

interesting someone used the same name and created something for openSUSE

They called it openSalux and call themselves BioLinux

http://susestudio.com/a/QhsNUm/open-salux

This is the kind of stuff that is not supposed to happen. 

Just one example. How is some outsider looking for an easy way to try great 
software supposed to diffentiate ?

Regards,
Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20271104.18364.sebastian.hilb...@gmx.net

Re: [FreeMedForms] Creating a global "Linux Medical Team"

[Sebastian Hilbert]

On Saturday, November 26, 2011 01:35:16 PM Steffen Möller wrote:

Hi all,

> :) This is quite some cross-posting.
> 
I agree with most points. However I would not be suprised *at all* if deb 
would be split in seperate versions. As soon as those million seat customers 
of canonical demand something Debian proper cannot cater for (let's hope that 
never happens) there is a good chance deb will never be the same again :-)

Same for Redhat and openSUSE.

Sebastian


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20261350.32508.sebastian.hilb...@gmx.net

Re: Free LIMS for genetic analyses and beyond anywhere?

[Sebastian Hilbert]

On Friday, November 25, 2011 01:39:00 PM Steffen Möller wrote:
> Dear all,
> 
> our lab's sample management does not scale and needs an overhaul. The
> idea is to migrate to an Open Source solution that fits the core needs
> (what sample sent by whom in what form in what freezer last used by whom
> for what project) and then have this adapted to our further needs.
> "needs" most likely mean image data (antibody staining of various tissues).
>

Have a look at CaBig's caTissue

https://cabig.nci.nih.gov/tools/catissuesuite

https://wiki.nci.nih.gov/display/caTissue/caTissue+Suite#caTissueSuite-
InstallationandDownloads

Regards,
Sebastian




--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20251355.42159.sebastian.hilb...@gmx.net

Re: FYI: sofastats

[Sebastian Hilbert]

On Friday, November 25, 2011 12:15:21 PM Sebastian Hilbert wrote:
> On Friday, November 25, 2011 12:07:40 PM Karsten Hilbert wrote:
> > On Fri, Nov 25, 2011 at 11:38:43AM +0100, Hilbert, Sebastian wrote:
> > > I wonder if this could be of interest for the Debian-med project or
> > > Debian in general.
> > > 
> > > SOFA Statistics

http://www.slideshare.net/grantps/sofa-statistics-developing-packaging-
promoting-a-python-open-source-project

Looks like the software is using almost indentical tools as GNUmed.

python
wxpython
can connect to postgresql
packaging done on windows through Nullsoft installer

The debian package was created following a totorial on ShowMeDo.

In short making it a proper package should be quite straightforward.

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20251244.22502.sebastian.hilb...@gmx.net

Re: FYI: sofastats

[Sebastian Hilbert]

On Friday, November 25, 2011 12:07:40 PM Karsten Hilbert wrote:
> On Fri, Nov 25, 2011 at 11:38:43AM +0100, Hilbert, Sebastian wrote:
> > I wonder if this could be of interest for the Debian-med project or
> > Debian in general.
> > 
> > SOFA Statistics
> > 
> > http://www.sofastatistics.com/downloads.php
> > 
> > There seems to be a *.deb but it might not be a clean package.
> 
> Debian already has popcon:
> 
>   http://qa.debian.org/popcon.php?package=gnumed-client
> 

??. You did look up the link ?

sofastats is a statisitcs program done in python and wxwidgets. It could be 
used to visualize data stored inside the gnumed database (lab values, gender 
distriution etc.) We are using gnuplot for this currently. 

Sebastian

> Package: popularity-contest
> Priority: optional
> Section: misc
> Installed-Size: 248
> Maintainer: Popularity Contest Developers
>  Architecture: all
> Version: 1.49
> Provides: popcon
> Depends: debconf (>= 0.5) | debconf-2.0, dpkg (>= 1.10)
> Recommends: cron | fcron, exim4 | mail-transport-agent
> Suggests: anacron
> Filename: pool/main/p/popularity-contest/popularity-contest_1.49_all.deb
> Size: 63890
> MD5sum: 0bc6a1e9f9c0b48ed84e0b076ddc9cb9
> SHA1: 9e114d9e7be5ff8525d6660e178384785f2d0231
> SHA256: 4c7482fb4f520aba542b587485055e2c133bc1ed1c1ee6684b906157e097fe63
> Description-de: Stimmen Sie automatisch über Ihre Lieblingspakete ab
>  Das Paket popularity-contest richtet einen cron-Job ein, der in
>  regelmäßigen Abständen eine anonymisierte Statistik über die am meisten
>  verwendeten Debian-Pakete auf diesem System an die Debian-Entwickler
>  versendet.
>  .
>  Diese Information hilft Debian, Entscheidungen zu treffen, z. B. welche
>  Pakete auf die erste Debian-CD gepackt werden sollen. Außerdem unterstützt
>  es Debian bei der Verbesserung zukünftiger Versionen, so dass die
>  beliebtesten Pakete diejenigen sind, die automatisch für neue Benutzer
>  installiert werden.
> Homepage: http://popcon.debian.org/
> Tag: implemented-in::perl, interface::commandline, role::program,
> scope::utility, suite::debian, use::transmission,
> works-with::software:package
> 
> Package: popularity-contest
> Version: 1.53
> Installed-Size: 252
> Maintainer: Popularity Contest Developers
>  Architecture: all
> Provides: popcon
> Depends: debconf (>= 0.5) | debconf-2.0, dpkg (>= 1.10)
> Pre-Depends: debconf (>= 1.5.34) | cdebconf (>= 0.106)
> Recommends: cron | fcron, exim4 | mail-transport-agent
> Suggests: anacron
> Description-de: Stimmen Sie automatisch über Ihre Lieblingspakete ab
>  Das Paket popularity-contest richtet einen cron-Job ein, der in
>  regelmäßigen Abständen eine anonymisierte Statistik über die am meisten
>  verwendeten Debian-Pakete auf diesem System an die Debian-Entwickler
>  versendet.
>  .
>  Diese Information hilft Debian, Entscheidungen zu treffen, z. B. welche
>  Pakete auf die erste Debian-CD gepackt werden sollen. Außerdem unterstützt
>  es Debian bei der Verbesserung zukünftiger Versionen, so dass die
>  beliebtesten Pakete diejenigen sind, die automatisch für neue Benutzer
>  installiert werden.
> Homepage: http://popcon.debian.org/
> Tag: implemented-in::perl, interface::commandline, role::program,
> scope::utility, suite::debian, use::transmission,
> works-with::software:package Section: misc
> Priority: optional
> Filename: pool/main/p/popularity-contest/popularity-contest_1.53_all.deb
> Size: 65406
> MD5sum: ac0f4f4993e5ef67b3c18528a50f29c1
> SHA1: 4b4df5181c75a662842a7a67dfd7c702492ef35a
> SHA256: 9145a6f753db00d9bc9faded0225de2eb6f35373d514c52e52968694211f1f98
> 
> 
> Karsten


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20251215.22005.sebastian.hilb...@gmx.net

FYI: sofastats

[Sebastian Hilbert]

Hi all,

I wonder if this could be of interest for the Debian-med project or Debian in 
general.

SOFA Statistics

http://www.sofastatistics.com/downloads.php

There seems to be a *.deb but it might not be a clean package.

Regards,
Sebastian Hilbert


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20251138.57610.sebastian.hilb...@gmx.net

Re: Ginkgo-CADx segfaults

[Sebastian Hilbert]

On Friday, November 11, 2011 10:42:23 PM Mathieu Malaterre wrote:
> On Fri, Nov 11, 2011 at 10:26 PM, Sebastian Hilbert
> 
>  wrote:
> > On Friday, November 11, 2011 09:42:23 PM Mathieu Malaterre wrote:
> >> On Fri, Nov 11, 2011 at 6:12 PM, Sebastian Hilbert
> >> 
> >>  wrote:
> >> > On Friday, November 11, 2011 01:55:51 AM Steve M. Robbins wrote:
> >> >> On Thu, Nov 10, 2011 at 10:23:01AM +0100, Sebastian Hilbert wrote:
> >> >> > On Thursday, November 10, 2011 10:03:09 AM Steffen Möller wrote:
> >> >> > > Sorry for saying the obvious here, but if the bug is not
> >> >> > > Debian-specific, then it should go to ITK upstream.
> >> >> 
> >> >> I definitely encourage that patches for upstream bugs be sent
> >> >> upstream.
> >> >> 
> >> >> > The question was more along the lines if Debian packages accept
> >> >> > patches which upstream refuses (have not checked with upstream ITK
> >> >> > but have had issues with wxwidgets).
> >> >> 
> >> >> It's common for Debian to have patches not in upstream.  Often, in my
> >> >> experience, it's not because of upstream refusal but due to differing
> >> >> priority or differing release cycles.  I generally have a number of
> >> >> patches for Boost that upstream takes multiple releases to
> >> >> incorporate.
> >> >> 
> >> >> If you have a patch for the problem, I encourage you to submit a
> >> >> Debian bug report as well as the upstream one, and link them.
> >> > 
> >> > Raising this problem upstream at Ginkgo I was pointed to
> >> > 
> >> > this bug report against itk upstream
> >> > 
> >> > https://itk.icts.uiowa.edu/jira/browse/ITK-2457
> >> > 
> >> > The comment from Mathieu there made me check which gdcm
> >> > libinsighttolkit depends on in Debian
> >> > 
> >> > http://packages.debian.org/sid/libinsighttoolkit3.20
> >> > 
> >> > This however indicates that it already depends on gdcm 2.x
> >> > 
> >> > which in turn means the bug is not fixed ?
> >> > 
> >> > Supposedly most work is on itk4 which might make the problem go away.
> >> 
> >> That's correct. ITK in debian has not been using the old GDCM 1.x
> >> where a static buffer was used to decompress JPEG segment since years.
> >> ITK uses a thread safe implementation in GDCM 2.x. I would think the
> >> issue is not the one described in bug ITK-2457
> >> 
> >> HTH
> > 
> > Now that I think of it upstream release 2.6.0 seems to work better. I
> > will follow up on this when this is packaged for Debian.
> > 
> > Has the patch mentioned ever made it into ITK ?
> 
> There is no "patch" per-say. ITK policy is very strict with regards to
> backward compatible API. Unfortunately GDCM 2.x did break quite a lot
> of GDCM 1.x API. Since the low level GDCM API was used so much, it was
> considered that breaking GDCM API would mean breaking ITK API, and
> thus never made it officially into ITK. ITKv4 effort was specifically
> designed with this goal in mind: break the API and cleanup old cruft.
> 
> Because I needed better DICOM functionalities in ITK, I made an option
> 'system GDCM' from the ITK configuration which allowed advanced users
> to compile ITK against both a GDCM 1.x and GDCM 2.x API.
> 
> I believe there has been a first rc for ITKv4, so this issue should
> soon be solved.
>

I will wait for that. Thanks for the info.
There seems to be another issue in that Ginkgo-CADx from Unstable uses 
libinsighttoolkit3.20.

Ginkgo cannot open a dicom file I have available since updating from 
libinsighttoolkit3.18 to 3.20.

I will raise this issue upstream.

Regards,
Sebastian
 
> HTH


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131000.39022.sebastian.hilb...@gmx.net

Re: Ginkgo-CADx segfaults

[Sebastian Hilbert]

On Friday, November 11, 2011 09:42:23 PM Mathieu Malaterre wrote:
> On Fri, Nov 11, 2011 at 6:12 PM, Sebastian Hilbert
> 
>  wrote:
> > On Friday, November 11, 2011 01:55:51 AM Steve M. Robbins wrote:
> >> On Thu, Nov 10, 2011 at 10:23:01AM +0100, Sebastian Hilbert wrote:
> >> > On Thursday, November 10, 2011 10:03:09 AM Steffen Möller wrote:
> >> > > Sorry for saying the obvious here, but if the bug is not
> >> > > Debian-specific, then it should go to ITK upstream.
> >> 
> >> I definitely encourage that patches for upstream bugs be sent
> >> upstream.
> >> 
> >> > The question was more along the lines if Debian packages accept
> >> > patches which upstream refuses (have not checked with upstream ITK
> >> > but have had issues with wxwidgets).
> >> 
> >> It's common for Debian to have patches not in upstream.  Often, in my
> >> experience, it's not because of upstream refusal but due to differing
> >> priority or differing release cycles.  I generally have a number of
> >> patches for Boost that upstream takes multiple releases to
> >> incorporate.
> >> 
> >> If you have a patch for the problem, I encourage you to submit a
> >> Debian bug report as well as the upstream one, and link them.
> > 
> > Raising this problem upstream at Ginkgo I was pointed to
> > 
> > this bug report against itk upstream
> > 
> > https://itk.icts.uiowa.edu/jira/browse/ITK-2457
> > 
> > The comment from Mathieu there made me check which gdcm libinsighttolkit
> > depends on in Debian
> > 
> > http://packages.debian.org/sid/libinsighttoolkit3.20
> > 
> > This however indicates that it already depends on gdcm 2.x
> > 
> > which in turn means the bug is not fixed ?
> > 
> > Supposedly most work is on itk4 which might make the problem go away.
> 
> That's correct. ITK in debian has not been using the old GDCM 1.x
> where a static buffer was used to decompress JPEG segment since years.
> ITK uses a thread safe implementation in GDCM 2.x. I would think the
> issue is not the one described in bug ITK-2457
> 
> HTH

Now that I think of it upstream release 2.6.0 seems to work better. I will 
follow up on this when this is packaged for Debian.

Has the patch mentioned ever made it into ITK ?

Sebastian


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20112226.31818.sebastian.hilb...@gmx.net

Re: Ginkgo-CADx segfaults

[Sebastian Hilbert]

On Friday, November 11, 2011 01:55:51 AM Steve M. Robbins wrote:
> On Thu, Nov 10, 2011 at 10:23:01AM +0100, Sebastian Hilbert wrote:
> > On Thursday, November 10, 2011 10:03:09 AM Steffen Möller wrote:
> > > Sorry for saying the obvious here, but if the bug is not
> > > Debian-specific, then it should go to ITK upstream.
> 
> I definitely encourage that patches for upstream bugs be sent
> upstream.
> 
> > The question was more along the lines if Debian packages accept patches
> > which upstream refuses (have not checked with upstream ITK but have had
> > issues with wxwidgets).
> 
> It's common for Debian to have patches not in upstream.  Often, in my
> experience, it's not because of upstream refusal but due to differing
> priority or differing release cycles.  I generally have a number of
> patches for Boost that upstream takes multiple releases to
> incorporate.
> 
> If you have a patch for the problem, I encourage you to submit a
> Debian bug report as well as the upstream one, and link them.
>

Raising this problem upstream at Ginkgo I was pointed to 

this bug report against itk upstream

https://itk.icts.uiowa.edu/jira/browse/ITK-2457

The comment from Mathieu there made me check which gdcm libinsighttolkit 
depends on in Debian

http://packages.debian.org/sid/libinsighttoolkit3.20
 
This however indicates that it already depends on gdcm 2.x

which in turn means the bug is not fixed ?

Supposedly most work is on itk4 which might make the problem go away.

Regards,
Sebastian


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111812.50103.sebastian.hilb...@gmx.net

Re: Ginkgo-CADx segfaults

[Sebastian Hilbert]

On Thursday, November 10, 2011 10:03:09 AM Steffen Möller wrote:

Hi all,

> On 11/10/2011 09:21 AM, Andreas Tille wrote:
> > On Thu, Nov 10, 2011 at 08:49:11AM +0100, Sebastian Hilbert wrote:
> >> I am currently working with upstream to get some problems corrected.
> >> Turns out that part of the problem is that e.g. ITK would need patches.
> >> 
> >> How would you consider the chances that those patches find their way
> >> into Debian packages ?
> > 
> > I'd file a (minor ??? - depending how general this problem is) bug
> > report with patch against ITK package and add an "affects #648167" tag
> > to stress the importance for GinkgoCADx.
> 
> Sorry for saying the obvious here, but if the bug is not
> Debian-specific, then it should go to ITK upstream. Such issues are
> (part of) why I am so much after getting upstream involved in the
> distribution woes, be they maintainers or just visiting our sprints.
> Just, we cannot be involved with everyone directly.
> 

Thanks for the pointers.

The question was more along the lines if Debian packages accept patches which 
upstream refuses (have not checked with upstream ITK but have had issues with 
wxwidgets).

Sebastian


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101023.01789.sebastian.hilb...@gmx.net

Ginkgo-CADx segfaults

[Sebastian Hilbert]

Hi al,

I am currently working with upstream to get some problems corrected. Turns out 
that part of the problem is that e.g. ITK would need patches.

How would you consider the chances that those patches find their way into 
Debian packages ?

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100849.11559.sebastian.hilb...@gmx.net

Re: Ginkgo-Cadx

[Sebastian Hilbert]

On Thursday, November 03, 2011 09:33:05 PM Sebastian Hilbert wrote:
Hi,

Has anyone tried Ginkgo-CADx 2.5.4. final as a Debian package. I am currently 
only testing on Oneiric where the Debian package builds without any tweaks.

I experience a number of problems which seem not to be there with the orignal 
'frozen' version that is shipped by upstream.

Please test and let me know if you 

1.) experience any sequfaults when you close a tab (especially the first one)
2.) can close tabs without crashing and at all
3.) can exit the application via menu (item exit)
4.) see strange colors when loading 
http://www.gnumed.de/downloads/dicom/iE33%20V2007%20Contrast
5.) can open more then one study at the same time

I will check with upstream but I believe there still must be some differecences 
in the systems libraries vs. the frozen libraries (patched maybe?) used by 
upstream.

Best regards,
Sebastian Hilbert


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20051844.14113.sebastian.hilb...@gmx.net

Ginkgo-Cadx feature wishlist opened

[Sebastian Hilbert]

Hi all,

The devs of the Dicom viewer Ginkgo-CADx are looking for input on what 
features to implent in the upcoming version 3.0. 

So if you have an itch to scratch let them know.

Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20041205.28069.sebastian.hilb...@gmx.net

Re: OpenClinica in Debian-Med

[Sebastian Hilbert]

On Friday, November 04, 2011 09:16:43 AM Sebastian Hilbert wrote:
> On Thursday, November 03, 2011 03:46:32 PM Olivier Sallou wrote:
> 
> It looks like when building OC all of the jars mentioned below are compiled
> from source anyway.

Ok. So here is what I did to compile it.

1.) checked out source code for OC 3.1 snapshot
svn co 
https://svn.akazaresearch.com/openclinica/OpenClinica/branches/OpenClinica-3.1-
SNAPSHOT/

2.) changed to folder \core
3.) ran mvn clean compile install -Dmaven.test.skip=true
4.) changed to the \web folder.
5.) Executed mvn clean compile war:war

It went through without problems.

I guess the next step would be to produce a package which

checks the runtime dependencies:
apt-get install postgresql
apt-get install opne-jdk-6-jdk tomcat6 tomcat6-admin tomcat6-common tomcat6-
docs tomcat6-examples

actually installs the contents to the correct locations
I downloaded the zip they provide and followed this guide on where to put the 
war files and where to create a few directories.

http://en.wikibooks.org/wiki/OpenClinica_User_Manual/Ubuntu1010

Regards,
Sebastian Hilbert

Re: OpenClinica in Debian-Med

[Sebastian Hilbert]

On Friday, November 04, 2011 09:50:52 AM Olivier Sallou wrote:
> Le 11/4/11 9:39 AM, Sebastian Hilbert a écrit :
> > On Friday, November 04, 2011 09:27:48 AM Olivier Sallou wrote:
> >> Le 11/4/11 9:16 AM, Sebastian Hilbert a écrit :
> >>> On Thursday, November 03, 2011 03:46:32 PM Olivier Sallou wrote:
> >>> 
> >>> It looks like when building OC all of the jars mentioned below are
> >>> compiled from source anyway.
> >> 
> >> I see in trunk it is a maven project [1]
> >> It gets all dependencies from a maven repository.
> >> Maven is quite an issue in Debian from my recent experience. While there
> >> are some helpers to manage this, you need to get
> >> all dependencies in Debian but also set for maven use.
> >> 
> >> For your package, you cannot use the maven repos.
> > 
> > Forgive my ignorance but why is that ?
> 
> With maven, you download some jar files located in a remote repository
> (maven or other).
> So, to build your package, you would download files from an other
> location, not using debian libs, furthermore there is no control on
> remote jar license, source availability etc...
> 

Thanks for pointing that out. How about shipping the sources for the jars in 
the OC tarball ?

I have cheched the licenses for the jars (see previous mails)

During packaging the jars could be built locally if that is possible.

> > Anyway I had a quick look and found this:
> > http://wiki.debian.org/Java/MavenBuilder
> 
> I never tested it, but already had a look. If I am correct, the mvn
> helper "translate" dependencies to Debian dependencies, but those
> dependencies need to have a pom file (maven descriptor). And for those
> not available in Debian, it won't solve the problem
> The script will create a local repository to be used by maven.
> 
The local repository could somehow be created from the sources for the jars 
shipped in the to be created OC tarball. So what you are saying is that for 
building a package all dependencies have to be on the build system and it is 
not acceptable to fetch them from somewhere ?

Regards,
Sebastian


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20041001.45912.sebastian.hilb...@gmx.net

Re: OpenClinica in Debian-Med

[Sebastian Hilbert]

On Friday, November 04, 2011 09:27:48 AM Olivier Sallou wrote:
> Le 11/4/11 9:16 AM, Sebastian Hilbert a écrit :
> > On Thursday, November 03, 2011 03:46:32 PM Olivier Sallou wrote:
> > 
> > It looks like when building OC all of the jars mentioned below are
> > compiled from source anyway.
> 
> I see in trunk it is a maven project [1]
> It gets all dependencies from a maven repository.
> Maven is quite an issue in Debian from my recent experience. While there
> are some helpers to manage this, you need to get
> all dependencies in Debian but also set for maven use.
> 
> For your package, you cannot use the maven repos.
> 
Forgive my ignorance but why is that ?

Anyway I had a quick look and found this:
http://wiki.debian.org/Java/MavenBuilder

is there a policy in Debian that helper scripts need to be used ?

In another email I will describe my thoughts on packaging OC. Please comment 
which parts are not compatible with Debian's way of doing things.

Regards,
Sebastian


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20040939.13050.sebastian.hilb...@gmx.net

Re: OpenClinica in Debian-Med

[Sebastian Hilbert]

On Thursday, November 03, 2011 03:46:32 PM Olivier Sallou wrote:

It looks like when building OC all of the jars mentioned below are compiled 
from source anyway.

They seem to be gotten from
svn.akazaresearch.com/ocrepository/repository/

So this looks like there is nothing to worry about ?

The OC developers are interested in packaging this so if there are any specific 
questions we have someone to talk to upstream.

the instructions for building OC from source are available at
https://wiki.openclinica.com/doku.php?id=developerwiki:gettingstarted

There they talk about trunk but I the path for OC 3.1 is
https://svn.akazaresearch.com/openclinica/OpenClinica/branches/OpenClinica-3.1-
SNAPSHOT/

Please let me know if that makes it possible to package OC and what effort is 
involved ?

Regards,
Sebastian

> Le 11/3/11 3:35 PM, Sebastian Hilbert a écrit :
> > On Monday, October 31, 2011 01:59:44 PM Sebastian Hilbert wrote:
> > 
> > I have done some more research on which jar files are needed by
> > OpenClinica
> > 
> > Here is a (maybe incomplete list)
> > 
> > There are a few occurences where no package in Debian provides the jar.
> > However for all jars sources exist and their is a license which should
> > comply with Debian guidelines (see below)
> > 
> > Please advise.
> 
> Regarding mail, there is gnumail I think that should match
> 
> > activation-1.0.2.jar - libgnujaf-java in sid
> > antlr-2.7.6.jar - antlr in sid
> > aopalliance-1.0.jar - libaopalliance-java in sid
> > aspectjrt-1.6.8.jar - libaspectj-java in sid
> > aspectjweaver-1.6.8.jar - libaspectj-java in sid
> > avalon-framework-api-4.3.1.jar - libavalon-framework-java in sid
> > avalon-framework-impl-4.3.1.jar - libavalon-framework-java in sid
> > batik-anim-1.7.jar - libbatik-java in sid
> > batik-awt-util-1.7.jar - libbatik-java in sid
> > batik-bridge-1.7.jar - libbatik-java in sid
> > batik-css-1.7.jar - libbatik-java in sid
> > batik-dom-1.7.jar - libbatik-java in sid
> > batik-ext-1.7.jar - libbatik-java in sid
> > batik-extension-1.7.jar - libbatik-java in sid
> > batik-gvt-1.7.jar - libbatik-java in sid
> > batik-parser-1.7.jar - libbatik-java in sid
> > batik-script-1.7.jar - libbatik-java in sid
> > batik-svg-dom-1.7.jar - libbatik-java in sid
> > batik-svggen-1.7.jar - libbatik-java in sid
> > batik-transcoder-1.7.jar - libbatik-java in sid
> > batik-util-1.7.jar - libbatik-java in sid
> > batik-xml-1.7.jar - libbatik-java in sid
> > bcmail-jdk14-138.jar - libcmail-java in sid
> > bcprov-jdk14-138.jar - libcprov-java in sid
> > castor-1.2.jar - ?? not in debian - www.castor.org - Apache-2.0-style
> > license castor-core-1.3.1.jar - libcastor-core-java in sid
> > castor-xml-1.3.1.jar - libcastor-core-xml in sid
> > cglib-nodep-2.1_3.jar - libcglib2.1-java in sid
> > commons-beanutils-1.8.0.jar - libcommons-beantutils-java in sid
> > commons-codec-1.3.jar - libcommons-codec-java in sid
> > commons-collections-3.2.1.jar - libcommons-collections-java in sid
> > commons-dbcp-1.2.2.jar - libcommons-dhcp-java in sid
> > commons-digester-1.7.jar - libcommons-digester-java in sid
> > commons-discovery-0.2.jar - libcommons-dicovery-java in sid
> > commons-fileupload-1.2.1.jar - libcommons-fileupload-java in sid
> > commons-httpclient-3.0.1.jar - libcommons-httpclient-java in sid
> > commons-io-1.4.jar - libcommons-io-java in sid
> > commons-lang-2.3.jar - libcommons-lang-java in sid
> > commons-logging-1.0.4.jar - libcommons-logging-java in sid
> > commons-logging-api-1.0.4.jar - libcommons-logging-java in sid
> > commons-math-1.1.jar - libcommons-math-java in sid
> > commons-pool-1.3.jar - libcommons-pool-java in sid
> > commons-validator-1.3.1.jar - libcommons-validator-java in sid
> > dom4j-1.6.1.jar - libdom4j-java in sid
> > fop-1.0.jar - fop in sid
> > hibernate-annotations-3.5.1-Final.jar - libhibernate-annotations-java
> > (3.6) hibernate-commons-annotations-3.2.0.Final.jar -
> > libhibernate-commons- annotations-java
> > hibernate-core-3.5.1-Final.jar - libhibernate3-java (3.6)
> > hibernate-jpa-2.0-api-1.0.0.Final.jar - not in Debian (LGPL)
> > hibernate-validator-4.0.2.GA.jar - libhibernate-validator-java in sid
> > itext-2.1.2.jar - libitext-java in sid
> > jackson-core-asl-1.5.3.jar - libjackson-json-java in sid
> > jackson-mapper-asl-1.5.3.jar - libjackson-json-java in sid
> > janino-2.5.10.jar - janino in sid
> > javassist-3.8.0.GA.jar - libjavassist-java (3.12 sid) (3.8 lenny)
> > jaxb-api-2.1.jar - libjaxme-java in sid (jaxmeapi.jar) ? or included in
> > openjdk ? license: CDDL / GPLv2
> > jaxb

Ginkgo-Cadx

[Sebastian Hilbert]

Hi,

It is great that Ginkgo-CADx is finally in Debian. I tried to make it available 
in Ubuntu Natty and Oneiric.

The failure for Natty is:

After installing, the following source dependencies are still unsatisfied:
libvtk5-dev(inst 5.4.2-8ubuntu4 ! >= wanted 5.6.0) libinsighttoolkit3-dev(inst 
3.18.0-5build2 ! >= wanted 3.20.0) 
libmysqlclient16(inst 5.1.54-1ubuntu4 ! >= wanted 5.1.57)
Source-dependencies not satisfied; skipping ginkgocadx
Could someone please comment on the versions of the dependencies.
Thanks,
Sebastian Hilbert

Re: OpenClinica in Debian-Med

[Sebastian Hilbert]

On Monday, October 31, 2011 01:59:44 PM Sebastian Hilbert wrote:

I have done some more research on which jar files are needed by OpenClinica

Here is a (maybe incomplete list)

There are a few occurences where no package in Debian provides the jar. 
However for all jars sources exist and their is a license which should comply 
with Debian guidelines (see below)

Please advise.

activation-1.0.2.jar - libgnujaf-java in sid
antlr-2.7.6.jar - antlr in sid
aopalliance-1.0.jar - libaopalliance-java in sid
aspectjrt-1.6.8.jar - libaspectj-java in sid
aspectjweaver-1.6.8.jar - libaspectj-java in sid
avalon-framework-api-4.3.1.jar - libavalon-framework-java in sid
avalon-framework-impl-4.3.1.jar - libavalon-framework-java in sid
batik-anim-1.7.jar - libbatik-java in sid
batik-awt-util-1.7.jar - libbatik-java in sid
batik-bridge-1.7.jar - libbatik-java in sid
batik-css-1.7.jar - libbatik-java in sid
batik-dom-1.7.jar - libbatik-java in sid
batik-ext-1.7.jar - libbatik-java in sid
batik-extension-1.7.jar - libbatik-java in sid
batik-gvt-1.7.jar - libbatik-java in sid
batik-parser-1.7.jar - libbatik-java in sid
batik-script-1.7.jar - libbatik-java in sid
batik-svg-dom-1.7.jar - libbatik-java in sid
batik-svggen-1.7.jar - libbatik-java in sid
batik-transcoder-1.7.jar - libbatik-java in sid
batik-util-1.7.jar - libbatik-java in sid
batik-xml-1.7.jar - libbatik-java in sid
bcmail-jdk14-138.jar - libcmail-java in sid
bcprov-jdk14-138.jar - libcprov-java in sid
castor-1.2.jar - ?? not in debian - www.castor.org - Apache-2.0-style license
castor-core-1.3.1.jar - libcastor-core-java in sid
castor-xml-1.3.1.jar - libcastor-core-xml in sid
cglib-nodep-2.1_3.jar - libcglib2.1-java in sid
commons-beanutils-1.8.0.jar - libcommons-beantutils-java in sid
commons-codec-1.3.jar - libcommons-codec-java in sid
commons-collections-3.2.1.jar - libcommons-collections-java in sid
commons-dbcp-1.2.2.jar - libcommons-dhcp-java in sid
commons-digester-1.7.jar - libcommons-digester-java in sid
commons-discovery-0.2.jar - libcommons-dicovery-java in sid
commons-fileupload-1.2.1.jar - libcommons-fileupload-java in sid
commons-httpclient-3.0.1.jar - libcommons-httpclient-java in sid
commons-io-1.4.jar - libcommons-io-java in sid
commons-lang-2.3.jar - libcommons-lang-java in sid
commons-logging-1.0.4.jar - libcommons-logging-java in sid
commons-logging-api-1.0.4.jar - libcommons-logging-java in sid
commons-math-1.1.jar - libcommons-math-java in sid
commons-pool-1.3.jar - libcommons-pool-java in sid
commons-validator-1.3.1.jar - libcommons-validator-java in sid
dom4j-1.6.1.jar - libdom4j-java in sid
fop-1.0.jar - fop in sid
hibernate-annotations-3.5.1-Final.jar - libhibernate-annotations-java (3.6)
hibernate-commons-annotations-3.2.0.Final.jar - libhibernate-commons- 
annotations-java
hibernate-core-3.5.1-Final.jar - libhibernate3-java (3.6)
hibernate-jpa-2.0-api-1.0.0.Final.jar - not in Debian (LGPL)
hibernate-validator-4.0.2.GA.jar - libhibernate-validator-java in sid
itext-2.1.2.jar - libitext-java in sid
jackson-core-asl-1.5.3.jar - libjackson-json-java in sid
jackson-mapper-asl-1.5.3.jar - libjackson-json-java in sid
janino-2.5.10.jar - janino in sid
javassist-3.8.0.GA.jar - libjavassist-java (3.12 sid) (3.8 lenny)
jaxb-api-2.1.jar - libjaxme-java in sid (jaxmeapi.jar) ? or included in 
openjdk ? license: CDDL / GPLv2
jaxb-impl-2.1.3.jar - libjaxme-java in sid (jaxmeapi.jar) ? or included in 
openjdk ? license: CDDL / GPLv2
jcl-over-slf4j-1.5.6.jar - libslj4j-java in sid
jdom-1.1.jar - libjdom1-java in sid
jmesa-2.4.2.jar - not in Debian - Apache 2 license
joda-time-1.6.jar - libjoda-time-java
jstl-1.1.2.jar - libjstl1.1-java
jta-1.1.jar - not in Debian either from Oracle (GPL) or libgeronimo-jta-1-1-
spec-java
jul-to-slf4j-1.5.6.jar - libslj4j-java in sid
jxl-2.6.6.jar - libjxcelapi-java in sid
liquibase-core-1.9.5.jar  - not in Debian (Apache 2.0)
liquibase-plugin-1.9.5.0.jar - not in Debian (Apache 2.0)
log4j-1.2.14.jar - liblog4j1.2-java in sid
logback-access-0.9.20.jar - not in Debian (EPL v1.0 or LGPL 2.1)
logback-classic-0.9.20.jar - liblogback-java in sid
logback-core-0.9.20.jar - liblogback-java in sid
mail-1.4.jar - not in Debian (CDDL license)
ojdbc14-10g.jar - not in Debian - closed - some Oracle distribution license - 
can skipped when using PG
OpenClinica-core-3.1.1-Community.jar - LPGL
openclinica-odm-0.1.0.BUILD-SNAPSHOT.jar - LGPL
oro-2.0.8.jar - liboro-java in sid
persistence-api-1.0.jar - not in Debian (Oracle CDDL) - shipped by glassfish-
javaee
pjl-comp-filter-1.6.4.jar - not in Debian (Apache 2.0)
poi-3.0.1-FINAL.jar - libapache-poi-java in sid
postgresql-8.1-404.jdbc3.jar - libpg-java in sid
quartz-1.8.0.jar - libquartz-java (1.7.3)
quartz-oracle-1.8.0.jar - not in Debian (not needed for PG)
rome-1.0.jar - librome-java in sid
rome-fetcher-1.0.jar - not in Debian (Apache 2)
saxon-8.7.jar - libsaxon-java in sid (6.5.5)
saxon-dom-8.7.jar - not in Debian (Mozilla Public license)
sitemesh-2.3.jar - libsitemesh-java in sid

OpenClinica in Debian-Med

[Sebastian Hilbert]

Hi back in the days I created this bug.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438868

Since I have not been involved with OpenClinica again and both Debian-med and 
OpenClinica have evolved quite a bit I wonder if there is any new interest in 
this.

Software is GPL and instrictions on how to compile it are here:

https://wiki.openclinica.com/doku.php?id=developerwiki:gettingstarted

Let me know if any additional info is needed.

Best regards,
Sebastian


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201110311359.44677.sebastian.hilb...@gmx.net

FOSS - eagle genomic

[Sebastian Hilbert]

FYI, maybe

http://www.floss4science.com/interview-eagle-genomics/

Regards,
Sebastian Hilbert


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201110281325.56158.sebastian.hilb...@gmx.net

Re: gnumed-client old icon

[Sebastian Hilbert]

On Friday, October 21, 2011 02:10:44 PM Andreas Tille wrote:
> On Fri, Oct 21, 2011 at 01:59:40PM +0200, Karsten Hilbert wrote:
> > > Replacing client/bitmaps/gnumed.xpm in your upstream tarball should
> > > work.
> > 
> > Which format does it have to be in ?
> 
> I'm not sure because I do not know freedesktop.org definition in very
> detail.  I'd *assume* svg and png should be safe.  Looking into your
> local harddisk what formats you are finding there should give a hint.
>

? In /usr/share/pixmaps I can only see xpm files.

http://en.wikipedia.org/wiki/X_PixMap

or create an xpm file

http://www.openwith.org/file-extensions/xpm/961
 
Sebastian Hilbert


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201110211429.10497.sebastian.hilb...@gmx.net