Re: Upload GNU Health 2.0 to experimental
* Andreas Tille: " Re: Upload GNU Health 2.0 to experimental" (Mon, 16 Sep 2013 16:15:57 +0200): ... > ... and this is what dbconfig-common is used for. Mathias, perhaps you > might like to have a look into dbconfig-common. Of course, will do. Moved two steps up on my Todo list. ... > > I'm eager to hear your comments/suggestions/critique! > > I personally like the way to do this. I admit I never went that far for > the gnumed-server package and upstream is happy about this. JFTR: Tryton upstream decided explicitly to not provide all-in-one packages for reasons of flexibility and security. Cheers, Mathias -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: Upload GNU Health 2.0 to experimental
On Mon, Sep 16, 2013 at 09:00:37PM +0200, Andreas Tille wrote: > On Mon, Sep 16, 2013 at 08:25:18PM +0200, Karsten Hilbert wrote: > > Regarding database upgrades one needs to ask oneself one > > simple question: > > > > Can users still connect to the previous database after a > > database upgrade ? > > > If so then upgrading at package install time is fine. > > > > If not then upgrading at package install time is insane. > > You can answer your question yourself when reading above. I know. That's why they are rethorical. Such sometimes help to spotlight points one had maybe not considered so far. Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- 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/20130916193805.gn3...@hermes.hilbert.loc
Re: Upload GNU Health 2.0 to experimental
Regarding database upgrades one needs to ask oneself one simple question: Can users still connect to the previous database after a database upgrade ? If so then upgrading at package install time is fine. If not then upgrading at package install time is insane. Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- 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/20130916182518.gk3...@hermes.hilbert.loc
Re: Upload GNU Health 2.0 to experimental
Hi, On Mon, Sep 16, 2013 at 08:25:18PM +0200, Karsten Hilbert wrote: > Regarding database upgrades one needs to ask oneself one > simple question: > > Can users still connect to the previous database after a > database upgrade ? In case of gnumed-server I would simply call the upgrade script provided by upstream (=you) via dbconfig-common. But there is no reason to be afraid: There is a stack of other things higher on my todo list. > If so then upgrading at package install time is fine. > > If not then upgrading at package install time is insane. You can answer your question yourself when reading above. Kind regards Andreas. -- 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/20130916190037.gb24...@an3as.eu
Re: Upload GNU Health 2.0 to experimental
* Emilien Klein: " Re: Upload GNU Health 2.0 to experimental" (Mon, 16 Sep 2013 15:44:49 +0200): > 2013/9/16 Mathias Behrle > > > * Emilien Klein: " Re: Upload GNU Health 2.0 to experimental" (Sun, 15 Sep > > 2013 > > 23:32:14 +0200): > > > > > So what happens here is: > > > gnuhealth-server depends on tryton-server > > > tryton-server recommends on postgres > > > > > > When installing the gnuhealth-server and all its dependencies, the > > packages > > > get configured in this order: > > > tryton-server > > > gnuhealth-server > > > postgres > > > > > > Since gnuhealth-server is using dbconfig-common to configure the > > database, > > > it needs postgres configured and running. On my development box, that was > > > the case (since dpkg -i doesn't pull in the dependencies, I had always > > > installed those manually beforehand). But when installing on a system > > that > > > doesn't have postgres installed, the incorrect order results in gnuhealth > > > not being configured properly. > > > > > > I had wrongly assume that tryton-server would depend on postgres. But > > since > > > that package requires manual configuration from it's user, they're > > actually > > > fine with only suggesting it (when installing with apt-get/aptitude, by > > > default the dependencies are pulled in), so for most users of the > > > tryton-server package, suggesting has virtually the same end effect as > > > depending: > > > > As you say above: postgresql is in Recommends, not in Suggests. > > tryton-server > > is multi-database capable with a strong preference for postgresql. So > > Recommends > > is the correct place for postgresl /nad will be pulled in default > > installations). > > > > It is great that Tryton is multi-database capable, and that's what the > Debian package should provide. Why not depend on (for instance) "postgres | > mysql | "? Because Tryton also works with sqlite and sqlite is in Python. This is also the default database used for testing and with neso. You don't want to install some full fledged database when only using neso. With respect to neso, postgresql in Recommends is already too much... > Maybe the question is how to support a user that wants to have it's > database on another server. Is there some kind of dummy "server not located > on this machine" package? That's exactly the generic layout of tryton-server. It is out of scope of the base packages to provide installation routines for each and every special use case. > > > postgres will be configured on the system before the user hand-edits the > > > configuration files. > > > > I did not have yet a look at the current package, but I see some potential > > conflicts here. I think you should never interfere with the package > > configuration on the system, be it from the package installation, be it by > > the > > sysadmin. As a solution I would propose to create a completely separate > > postgresql cluster for gnuhealth, for which you are free to configure > > everything like you want (thus avoiding problems with systems running > > postgresql before and besides gnuhealth). > > > > > I completely agree, a package should never interfere with the configuration > of another package (and we're not doing that in any way). The GNU Health > package is using the default configuration of Postgres on Debian, and is > also not changing anything to the configuration of the Tryton server. > > I think what is needed is to take a step back: what is the goal of > packaging a piece of software in Debian? > The original version of the GNU Health package did nothing more than > placing the code on the system, and left the user to take care of the > configuration (database, etc.). In fact, pretty similar to what the Tryton > package does (printing a bit blob of text telling the user to look at the > documentation to set up the system). As discussed with Andreas [0], that is > not helpful for the user (not very much more than if the user had > downloaded a tarball and extracted it to his system). This "blob of text" ;) is due to replacement. > Although Debian might have a reputation of not being the most user > friendly, we nonetheless strive to make the user's life as easy as > possible, and provide packages that (as much as possible) work out of the > box after an `apt-get install`. I agree with 'as much as possible', which also means: keep all the possibilities of running Tryton as cluster against a database cluster and nevertheless to not install software that is basically not needed for individual use cases. If you want to package gnuhealth as a standalone package for one machine and to get users fast into touch with the software, the current layout may fit. It won't fit very well for installations running the Tryton server(s) on (a) different machine(s) than the database server(s). I pointed this already out in [1]. > And that's what is happening with GNU Health: it installs the code, but > also sets up a database
Re: Biological data being used by an unpublished research paper is considered proprietary
Jeff Epler writes: > Under US law, it may be the case that violating website terms of > service is a felony crime with jail time attached. The USA Federal courts have made it clear that this is not the case. As far as I know there have been no convictions or even prosecutions under this theory. A casual reading of the legislative history of this (execrable) law indicates that it was not the intent of Congress to criminalize such things as violation of TOS. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- 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/87li2wyeuh@thumper.dhh.gt.org
Re: Debian enquiry about data files in munsell (fwd)
Am Sonntag, 15. September 2013, 11:17:34 schrieb Charles Plessy: > Le Fri, Sep 13, 2013 at 11:21:58AM +0200, Benjamin Eikel a écrit : > > I wrote another e-mail on September 3, 2013 and asked for clarification, > > but I did not get an answer yet. > > Thanks a lot Benjamin and Faheem, > > if we do not have a better answer, then I think that the best would be to > summarise the result of your investigations in debian/README.source and > re-upload. I have uploaded such a file. I do not know if the information given there suffices and if citing the mails there is the right way. If you find the time, please take a look at it. > > By the way, I also found the Munsell data in psychtoolbox-3, maybe > this can be mentionned as well. > > Have a nice day, > > Charles -- 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/2205199.rMm1cYIWO3@pc-benjamin
Re: Biological data being used by an unpublished research paper is considered proprietary
It looks like both you and the site you wish to access are based in France, so please forgive this US-centric intrusion. Under US law, it may be the case that violating website terms of service is a felony crime with jail time attached. https://www.eff.org/deeplinks/2013/01/rebooting-computer-crime-law-part-1-no-prison-time-for-violating-terms-of-service Based on the scenario you describe, and if the communication passed through a system under US jurisdiction, you might be in violation of this stupid law. Jeff signature.asc Description: Digital signature
Re: Orthanc 0.6.1
Mathieu, Would you care explaining why you reverted my change. I did document in svn rev 14174 what I did. Furthermore to prevent anyone from reverting it, I took additional steps and even left the comment: "remove build type, see #711515" Sorry about this. I had not understood that your comment was related to the "CMAKE_BUILD_TYPE" option. I have reverted the change, and put the comment just next to this option to make things clearer to me [1]. Sébastien- [1] http://anonscm.debian.org/viewvc/debian-med?view=revision -- 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/52371345.3040...@chu.ulg.ac.be
Re: Upload GNU Health 2.0 to experimental
Hi, On Mon, Sep 16, 2013 at 03:44:49PM +0200, Emilien Klein wrote: > > As you say above: postgresql is in Recommends, not in Suggests. > > tryton-server > > is multi-database capable with a strong preference for postgresql. So > > Recommends > > is the correct place for postgresl /nad will be pulled in default > > installations). > > > > It is great that Tryton is multi-database capable, and that's what the > Debian package should provide. Why not depend on (for instance) "postgres | > mysql | "? I think this will not help in the gnuhealth case because the Dependency might be fullfilled by mysql which does not help in the gnuhealth case. So it is correct to make gnuhealth explicitly depend postgresql. > Maybe the question is how to support a user that wants to have it's > database on another server. Is there some kind of dummy "server not located > on this machine" package? Not that I'm aware of (and it would help neither in your case). > > I did not have yet a look at the current package, but I see some potential > > conflicts here. I think you should never interfere with the package > > configuration on the system, be it from the package installation, be it by > > the > > sysadmin. As a solution I would propose to create a completely separate > > postgresql cluster for gnuhealth, for which you are free to configure > > everything like you want (thus avoiding problems with systems running > > postgresql before and besides gnuhealth). > > > I completely agree, a package should never interfere with the configuration > of another package (and we're not doing that in any way). The GNU Health > package is using the default configuration of Postgres on Debian, and is > also not changing anything to the configuration of the Tryton server. ... and this is what dbconfig-common is used for. Mathias, perhaps you might like to have a look into dbconfig-common. > I think what is needed is to take a step back: what is the goal of > packaging a piece of software in Debian? > The original version of the GNU Health package did nothing more than > placing the code on the system, and left the user to take care of the > configuration (database, etc.). In fact, pretty similar to what the Tryton > package does (printing a bit blob of text telling the user to look at the > documentation to set up the system). As discussed with Andreas [0], that is > not helpful for the user (not very much more than if the user had > downloaded a tarball and extracted it to his system). > > Although Debian might have a reputation of not being the most user > friendly, we nonetheless strive to make the user's life as easy as > possible, and provide packages that (as much as possible) work out of the > box after an `apt-get install`. > > And that's what is happening with GNU Health: it installs the code, but > also sets up a database and initializes the database so that a user gets a > working system after installing. If the user wants, he can still opt-out of > dbconfig-common's setup and skip all that to manually configure his system. > A user that would have a specific requirement can still manually edit the > config file, we're by no means preventing that: Freedom included! > > So to summarize, this is the goal of the GNU Health package in Debian > (let's discuss this if anybody disagree): > * Provide a working installation of GNU Health, out-of-the-box. A user > should just have to type `apt-get install gnuhealth` to have a working GNU > Health installation (both client and server) on his local machine, where > the client would automatically find the server installed on the same > machine. Unless the user wants it, no manual editing of configuration files > should be needed. > * Allow for modular installation: > - Install client-only on workstations (apt-get install gnuhealth-client) > - Install server-only on servers (apt-get install gnuhealth-server) > > I'm eager to hear your comments/suggestions/critique! I personally like the way to do this. I admit I never went that far for the gnumed-server package and upstream is happy about this. However, if I would have more time for this (or if somebody else would like to take the challenge) this would be a nice optional (ins the sense you said above) feature. Kind regards Andreas. -- 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/20130916141557.ga17...@an3as.eu
Re: Orthanc 0.6.1
Dear Sébastien, Would you care explaining why you reverted my change. I did document in svn rev 14174 what I did. Furthermore to prevent anyone from reverting it, I took additional steps and even left the comment: "remove build type, see #711515" thanks, On Mon, Sep 16, 2013 at 3:44 PM, Sebastien Jodogne wrote: > Dear all, > > I have just updated the DebianMed repository with the newest upstream > version of Orthanc (0.6.1) [1,2]. Mathieu, please would you kindly upload it > to unstable? Thanks in advance! > > Cheers, > Sébastien- > > [1] https://code.google.com/p/orthanc/ > [2] > http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc/trunk/debian/ > > > -- > 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/52370b2b.9010...@chu.ulg.ac.be > -- 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/CA+7wUsxuDxgjOxikRtyUGmiCobm0PTuAam5oU5ha=+cw+42...@mail.gmail.com
Re: Upload GNU Health 2.0 to experimental
2013/9/16 Mathias Behrle > * Emilien Klein: " Re: Upload GNU Health 2.0 to experimental" (Sun, 15 Sep > 2013 > 23:32:14 +0200): > > > So what happens here is: > > gnuhealth-server depends on tryton-server > > tryton-server recommends on postgres > > > > When installing the gnuhealth-server and all its dependencies, the > packages > > get configured in this order: > > tryton-server > > gnuhealth-server > > postgres > > > > Since gnuhealth-server is using dbconfig-common to configure the > database, > > it needs postgres configured and running. On my development box, that was > > the case (since dpkg -i doesn't pull in the dependencies, I had always > > installed those manually beforehand). But when installing on a system > that > > doesn't have postgres installed, the incorrect order results in gnuhealth > > not being configured properly. > > > > I had wrongly assume that tryton-server would depend on postgres. But > since > > that package requires manual configuration from it's user, they're > actually > > fine with only suggesting it (when installing with apt-get/aptitude, by > > default the dependencies are pulled in), so for most users of the > > tryton-server package, suggesting has virtually the same end effect as > > depending: > > As you say above: postgresql is in Recommends, not in Suggests. > tryton-server > is multi-database capable with a strong preference for postgresql. So > Recommends > is the correct place for postgresl /nad will be pulled in default > installations). > It is great that Tryton is multi-database capable, and that's what the Debian package should provide. Why not depend on (for instance) "postgres | mysql | "? Maybe the question is how to support a user that wants to have it's database on another server. Is there some kind of dummy "server not located on this machine" package? > > > postgres will be configured on the system before the user hand-edits the > > configuration files. > > I did not have yet a look at the current package, but I see some potential > conflicts here. I think you should never interfere with the package > configuration on the system, be it from the package installation, be it by > the > sysadmin. As a solution I would propose to create a completely separate > postgresql cluster for gnuhealth, for which you are free to configure > everything like you want (thus avoiding problems with systems running > postgresql before and besides gnuhealth). > > I completely agree, a package should never interfere with the configuration of another package (and we're not doing that in any way). The GNU Health package is using the default configuration of Postgres on Debian, and is also not changing anything to the configuration of the Tryton server. I think what is needed is to take a step back: what is the goal of packaging a piece of software in Debian? The original version of the GNU Health package did nothing more than placing the code on the system, and left the user to take care of the configuration (database, etc.). In fact, pretty similar to what the Tryton package does (printing a bit blob of text telling the user to look at the documentation to set up the system). As discussed with Andreas [0], that is not helpful for the user (not very much more than if the user had downloaded a tarball and extracted it to his system). Although Debian might have a reputation of not being the most user friendly, we nonetheless strive to make the user's life as easy as possible, and provide packages that (as much as possible) work out of the box after an `apt-get install`. And that's what is happening with GNU Health: it installs the code, but also sets up a database and initializes the database so that a user gets a working system after installing. If the user wants, he can still opt-out of dbconfig-common's setup and skip all that to manually configure his system. A user that would have a specific requirement can still manually edit the config file, we're by no means preventing that: Freedom included! So to summarize, this is the goal of the GNU Health package in Debian (let's discuss this if anybody disagree): * Provide a working installation of GNU Health, out-of-the-box. A user should just have to type `apt-get install gnuhealth` to have a working GNU Health installation (both client and server) on his local machine, where the client would automatically find the server installed on the same machine. Unless the user wants it, no manual editing of configuration files should be needed. * Allow for modular installation: - Install client-only on workstations (apt-get install gnuhealth-client) - Install server-only on servers (apt-get install gnuhealth-server) I'm eager to hear your comments/suggestions/critique! +Emilien [0] http://lists.alioth.debian.org/pipermail/debian-med-packaging/2012-November/017921.html
Orthanc 0.6.1
Dear all, I have just updated the DebianMed repository with the newest upstream version of Orthanc (0.6.1) [1,2]. Mathieu, please would you kindly upload it to unstable? Thanks in advance! Cheers, Sébastien- [1] https://code.google.com/p/orthanc/ [2] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/orthanc/trunk/debian/ -- 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/52370b2b.9010...@chu.ulg.ac.be
Re: Upload GNU Health 2.0 to experimental
* Emilien Klein: " Re: Upload GNU Health 2.0 to experimental" (Sun, 15 Sep 2013 23:32:14 +0200): > So what happens here is: > gnuhealth-server depends on tryton-server > tryton-server recommends on postgres > > When installing the gnuhealth-server and all its dependencies, the packages > get configured in this order: > tryton-server > gnuhealth-server > postgres > > Since gnuhealth-server is using dbconfig-common to configure the database, > it needs postgres configured and running. On my development box, that was > the case (since dpkg -i doesn't pull in the dependencies, I had always > installed those manually beforehand). But when installing on a system that > doesn't have postgres installed, the incorrect order results in gnuhealth > not being configured properly. > > I had wrongly assume that tryton-server would depend on postgres. But since > that package requires manual configuration from it's user, they're actually > fine with only suggesting it (when installing with apt-get/aptitude, by > default the dependencies are pulled in), so for most users of the > tryton-server package, suggesting has virtually the same end effect as > depending: As you say above: postgresql is in Recommends, not in Suggests. tryton-server is multi-database capable with a strong preference for postgresql. So Recommends is the correct place for postgresl /nad will be pulled in default installations). > postgres will be configured on the system before the user hand-edits the > configuration files. I did not have yet a look at the current package, but I see some potential conflicts here. I think you should never interfere with the package configuration on the system, be it from the package installation, be it by the sysadmin. As a solution I would propose to create a completely separate postgresql cluster for gnuhealth, for which you are free to configure everything like you want (thus avoiding problems with systems running postgresql before and besides gnuhealth). HTH, Mathias -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: contribute to useful tasks in medecine
Hi Julien, recently bug #722618 was fixed and translations should again migrate to the Debian package pool. I changed the Debian Med tasks pages to use ddtp.debian.net again (ddtp.debian.org is not yet used and DSA has shut down the machine). So you might like to inject the translations done on your local machine ... and everybody else who likes to do translations might also do so. As you can read in my post to debian-project[1] the the Debian I18n team is a bit short of man power. So if you think you could help out there a bit - that would be a great service also for Debian Med. Kind regards and it was nice to learn you to know at DebConf Andreas. [1] https://lists.debian.org/debian-project/2013/09/msg00065.html On Sun, Jul 21, 2013 at 11:23:21PM +0200, Julien Dordoigne wrote: > Guten Abend, > > I translated few packages > http://julien.dordoigne.free.fr/wiki/index.php?title=Medicine > The translate button looks still broken . > > Wir sehen uns bald. > Julien > > > 2013/7/19 Julien Dordoigne > > > > > > > -- Forwarded message -- > > From: Andreas Tille > > Date: 2013/7/18 > > Subject: Re: contribute to useful tasks in medecine > > To: Julien Dordoigne > > > > > > Hi Julien, > > > > at first: The most important rule we have and what I forgot to mention: > > Please lets do all discussion in public! The rationale behind this is > > that there might be people (now ... or in the future who seeked the > > mailing list archive) who are interested in the discussion. It is > > simply a waste of time to talk about the very same things in private > > mails and it is simply unfair to hide potentially valuable information > > from others. So feel free to quote me freely in your next reply to the > > public mailing list. > > > > On Thu, Jul 18, 2013 at 07:39:13PM +0200, Julien Dordoigne wrote: > > > Hello Andreas, > > > > > > Thanks for your message. I gonna to start as you mentionned . > > > When I click to the button "Traduire la description" , the request is > > sent, > > > it takes a while, then nothing happens. The same using Chrome or Internet > > > Explorer. I'm located over there at a village with a 5 Mbps connection > > > > > https://maps.google.fr/maps?q=the%20request%20is%20sent&um=1&ie=UTF-8&hl=en&sa=N&tab=Tl > > > > Well, I guess it is not your connection - currently I also get > > > > $ ping ddtp.debian.org > > PING ddtp.debian.org (206.12.19.128) 56(84) bytes of data. > > > > > > > By translating "debian.org", the server is located in > > > http://www.localiser-ip.com/?ip=128.31.0.51 . > > > Start for screenshots . Please let me know if you find a solution for the > > > translation option . Thanks . > > > > My first reaction would be to simply wait because any server in > > debian.org domain is observed by DSA (Debian Server Admin) team and they > > usually take action if needed. My guess is that this is just a > > temporary problem. If nothing has changed we should ask DSA. > > > > Kind regards and thanks for your intention to help > > > > Andreas. > > > > -- > > http://fam-tille.de > > > > > > > > -- > > Bien cordialement > > Julien Dordoigne > > > > > > > -- > Bien cordialement > Julien Dordoigne -- 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/20130916130522.ga16...@an3as.eu
Re: Biological data being used by an unpublished research paper is considered proprietary
On 16/09/2013 11:31, Faheem Mitha wrote: Hi, This is really not Debian-related, except insofar as the software in question is something that might have been in Debian one day. I talked about that with people on debian-med recently. So, it is technically off-topic. I posted a reply on stackexchange with instructions to get the data from the EBI SRS server. However, I have run into this issue before in the context of biological database entries and Debian so it may be worth discussing here. There were objections to including SwissProt entries in the example data for the EMBOSS package because the licensing of SwissProt does not allow them to be edited. That was resolved by agreeing that scientific facts should not be edited so that the files could be accepted as part of a Debian package even though they could not be changed. A fine compromise I feel. regards, Peter Rice EMBOSS team -- 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/5236f28f.2020...@yahoo.co.uk
Re: Biological data being used by an unpublished research paper is considered proprietary
I am not a lawyer but I don't think facts are copyrightable. In some jurisdictions there are "database rights" and copyright on collections of facts (like phone books) that could apply here. I suggest you consult the lawyers for your research institute for the legal situation in your jurisdiction. The script thing sounds silly and easy to work-around - fake the user-agent and put a few seconds between requests. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6ets4u6oykxfmoe3u1dofmo8jjehiwu_sgcagv500o...@mail.gmail.com
Biological data being used by an unpublished research paper is considered proprietary
Hi, This is really not Debian-related, except insofar as the software in question is something that might have been in Debian one day. I talked about that with people on debian-med recently. So, it is technically off-topic. However, I thought that maybe people on these lists would have some input on the matter. People in Debian are very experienced in matters of copyright and licensing, and people in debian-med presumably know something about copyright/licensing of biological data. I posted the following to academia.stackexchange.com, http://academia.stackexchange.com/q/12718/285 As I write there is one reply. Summary of my SE question: 1) A distributor of biological data is claiming proprietary ownership of the data. This runs contrary to what I know about such data. Can anyone comment? 2) The distributor also says a script to download the (200) data files is prohibited. Saying I cannot use a script to download the data (curl in my case) is in IMO downright bizarre. Is expecting a user to download 200 files manually reasonable, and how would the server tell the difference anyway? They're all just http requests. Please CC me on any reply. Thanks. Regards, Faheem # http://academia.stackexchange.com/q/12718/285 # This question may be too specialist to be on-topic here. In which case, please feel free to transfer it to another SE site, or close, as appropriate. I am planning to publish an applied statistics paper. This paper develops an algorithm and then applies this algorithm to some data. I obtained most of this data from the site http://www.imgt.org. The data I am using are immunoglobulin and T cell receptor nucleotide sequences, in the form of FASTA files. I'm using around 200 of these. Here is an [random example][1] of the data I am using (click on [6 Sequence (FASTA format)] to get the FASTA file). Now, I have a problem. In [Warranty Disclaimer and Copyright Notice](http://www.imgt.org/Warranty.html), is written The IMGT® software and data are provided as a service to the scientific community to be used only for research and educational purposes. Individuals may print or save portions of IMGT® for their own personal use. Any other use of IMGT® material need prior written permission of the IMGT director and of the legal institutions (CNRS and Université Montpellier 2). I just heard from Prof. Marie-Paule Lefranc and she replied: I have no objection that the data you retrieved for your work from IMGT/LIGM-DB be made available to the reviewers, but unfortunately we cannot authorize a script or a distribution of the IMGT/LIGM-DB files with your code to the users. You can provide the users with the list of the IMGT/LIGM-DB accession numbers you used, with the source of the data clearly identified: (IMGT/LIGM-DB version number) and reference to NAR 2006. Well, this just made my life more difficult. To start with, I'm puzzled by this. Isn't biological data like this public domain? Is it really possible to treat immunoglobulin and T cell receptor nucleotide sequence data as proprietary information? I just wrote back and asked Prof. Lefranc what license the data was published under, which I had not done earlier. Additionally, how does one make data available to reviewers and not to users? That is awkward, to say the least. ##
Re: Upload GNU Health 2.0 to experimental
Hi Emilien, On Sun, Sep 15, 2013 at 11:32:14PM +0200, Emilien Klein wrote: > OK, I've finally found what the issue was with GNU Health, and I believe > I've fixed it. Great! Thanks for working on this. > Can you please upload the newest package (in svn [0]) to experimental to be > able to test installing from a repo, pulling in all the dependencies > (that's where the issue was, see below for more explanation) Package just uploaded to experimental. > Since gnuhealth-server is using dbconfig-common to configure the database, > it needs postgres configured and running. On my development box, that was > the case (since dpkg -i doesn't pull in the dependencies, I had always > installed those manually beforehand). But when installing on a system that > doesn't have postgres installed, the incorrect order results in gnuhealth > not being configured properly. > > I had wrongly assume that tryton-server would depend on postgres. But since > that package requires manual configuration from it's user, they're actually > fine with only suggesting it (when installing with apt-get/aptitude, by > default the dependencies are pulled in), so for most users of the > tryton-server package, suggesting has virtually the same end effect as > depending: > postgres will be configured on the system before the user hand-edits the > configuration files. > > But since with GNU Health, we try to automate the whole process, we > actually need postgres to be configured before gnuhealth-server itself gets > configured. I have thus made the gnuhealth-server package depend on > postgres. Sounds logical. > After you upload the new 2.0.0-2 package to experimental, I'll first purge > all tryton and postgres packages before installing gnuhealth-server. This > time, postgres should get configured before gnuhealth-server, and all > should be fine! OK. > Please upload the new version to experimental. Done as said above. Kind regards Andreas. -- 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/20130916090313.gc6...@an3as.eu
