Re: Is a bug RC relevant if it has an influence on the health of a person
On Sat, Sep 11, 2010 at 07:46:34PM +0200, Goswin von Brederlow wrote: but reportbug did not let me specify either of RC / critical / grave / serious / security ... Because you are a reportbug novice. Or at least reportbug thinks so =:- But thanks anyway ;-) Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100913095307.ga3...@hermes.hilbert.loc
Re: Is a bug RC relevant if it has an influence on the health of a person
On Thu, Sep 09, 2010 at 11:40:49AM +0200, Andreas Tille wrote: with GNUmed we currently have a case where a bug is not RC regarding the computer system and would not match our criterion of RC bugs. However, the influence of this bug might harm the health of patients of the doctor who might use this version of GNUmed. If needed upstream will give some more details Hi, I am (one of) upstream; both developer and Medical Doctor (GP). The problem Andreas is talking about is this: Let's assume I am your GP. I prescribe the drug SugarWater(tm) against ObsessionForPackaging for you. Next day you must be admitted to hospital by emergency ambulance because it turns out you had a severe allergic reaction to Sugar (one component of SugarWater). We call that anaphylactic reaction [1] and you barely survive. When you return to my office I duly document your allergy to Sugar. However, you still need and receive Water for ObsessionForPackaging which we tried to treat with SugarWater. A week later you return and show me a new skin rash (exanthema). You suspect that you are also allergic to Water, the second component of SugarWater (remember, you still take Water pills every day, we only stopped Sugar because you were allergic to *that*). Now, because of your bad experience with Sugar and the new reaction to Water, you fear you will also develop an anaphylactic shock to Water (this is medically fairly unlikely but the fear is understandable). So we decide to use an entirely different drug against ObsessionForPacking. I also duly note your additional reaction towards Water in your EMR (which is GNUmed [2], the package in question). Here comes the bug: GNUmed will, given appropriate circumstances, OVERWRITE the first allergy against Sugar. Three years later, Debian 10 has been released and you return because of FatigueFromPackaging. I prescribe Sugar, which usually helps against FatigueFromPackaging. Your EMR does NOT contain the allergy entry for Sugar anymore because it was overwritten by the allergy to Water. You die in hospital because of a second anaphylactic reaction to Sugar. Of course, medico-legally I am responsible. However, didn't you wish we had discussed and solved this issue in Debian *today* ? ;-) Thanks for listening, Karsten Hilbert, MD, GP [1] http://en.wikipedia.org/wiki/Anaphylaxis [2] http://packages.debian.org/search?keywords=gnumed-client -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100909100358.gj2...@hermes.hilbert.loc
Re: Is a bug RC relevant if it has an influence on the health of a person
On Thu, Sep 09, 2010 at 12:38:05PM +0200, Michael Tautschnig wrote: Here comes the bug: GNUmed will, given appropriate circumstances, OVERWRITE the first allergy against Sugar. ... You die in hospital because of a second anaphylactic reaction to Sugar. [...] Although I do see the point of harms people missing in the description of severities, *all* RC-level severities already seem to apply, given the above description (quoting [1]): - critical: ... or causes serious data loss, ... (although internal to GNUmed, it does cause loss of a patient's data) - grave: makes the package in question unusable or mostly so, ... (given the above description, it shall better not be used by any medic) - serious: ... or, in the package maintainer's or release manager's opinion, makes the package unsuitable for release. (the easiest one: paste Karsten's description into a bug report and you're done) Filed a bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596219 but reportbug did not let me specify either of RC / critical / grave / serious / security ... Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100909110713.gm2...@hermes.hilbert.loc
Re: RFC: common database policy/infrastracture
but something to point out: dbconfig-common already performs the administrative actions needed to set up the database and database user Well, see, the GnuMed bootstrapping does a lot more advanced things regarding the database user. There's users and groups with varying levels of access to the database. However, if dbconfig-common creates the admin account we just use it. We can also deal with the fact that the database is pre-created, no problem. 2. From the application point of view I could ask people to include an option which prevents the bootstrap script from doing the work which is just done. I guess this is no big deal for the very responsive authors. Agree. We might need to double-check but I think we are in good shape on that already. for the admin pass, it should be configurable globally whether or not the admin password is stored at all. I think you need to be very clear on what you mean here. There is an admin account for *PostgreSQL* (eg. postgres in most cases) but there's also an admin account for the database gnumed inside PostgreSQL (usually called gm-dbowner). The latter one owns all objects in that database and grants rights to other user groups. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: Help wanted for packaging postgresql application
Andreas,
For the next problem I have no real clue for a solution. The
bootstrap method does access the database as the newly created user
this requires a change of the PostgreSQL configuration. To make the
problem clear look at the following shell script:
#!/bin/sh
TUSER=mytestuser
PASSW=jippi
HASUSER=`echo SELECT count(*) FROM pg_user WHERE usename = '${TUSER}'
| \
psql template1 | \
grep ^[[:space:]]*[0-9]\+ | \
sed s/^[[:space:]]*\([0-9]\+\)/\1/`
if [ $HASUSER -eq 0 ] ; then
echo CREATE USER ${TUSER} WITH PASSWORD '${PASSW}' CREATEDB | \
psql template1
else
echo User $TUSER exists.
fi
psql --username ${TUSER} --password template1 EOF
SELECT COUNT(*) FROM pg_tables
EOF
This ends in
psql: FATAL: IDENT authentication failed for user mytestuser
This does not fail because mytestuser has insufficient
rights inside PostgreSQL but beecause PostgreSQL tries to
verify general access rights to the database by trying to
match up the *database* user to the current *system* user via
identd. Since they don't match the access fails. Adding a line
to pg_hba.conf that allows database users other than the
executing system user to access the needed databases
restricted to, say, the local machine should alleviate this
problem. The auth_type must be set to passwd, crypt, md5 or some
such. Just not to IDENT or TRUST. (Well, TRUST should work but
we don't want that.)
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: [Gnumed-devel] Re: New project: Debian-Med
Hello Brian, hello Andreas, I have had inquiries by interested German doctors on how they can obtain a version of, say, GNUMed to try out on their machines at home. To date I have had to tell them: Go grab the source. A Debian-med distro will make such things a lot easier. May I suggest the following: For some projects it may be possible to create ISO images with the following properties: - Put it in a running machine and it starts a front end that connects to sample backends on the internet/started from this CD. - Put it in a booting machine and a minimalistic X-based Linux environment shows up running a demo version of the application in question. Now I know that this might very well eat up some serious resources but I thought I'd mention it anyway. For some projects it may not even be technically possible (You did notice that I never said that a project would _install_ itself onto the host machine ? Temporary files and necessary temporary path tweaks et al on the host system are, of course, OK.) Regards, Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
