Re: Initial Grinder package
> Does one generally need to ping you for every upload, or is it > generally sufficient to modify the changelog file from 'UNRELEASED' > to 'unstable'? Dear Florent, we only mark 'unstable' the changelogs of the packages that have been uploaded and not yet modified in the VCS. http://debian-med.alioth.debian.org/docs/policy.html#debian-changelog I reviewed your package, and will upload it shortly after updating the format of its copyright file. Note that since you are upstream author, you can also arrange the production of the manual pages within the Perl build system itself. Have a nice week-end, Charles -- Charles Plessy Debian Med packaging team http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120127060121.gc12...@merveille.plessy.net
Re: Initial Grinder package
Hi Andreas, Thank you for your advices. The only thing I would like you to change is the authorship of the manpages. While it is correct that you can claim yourself as the author of the manpage it would be more precise to inform that you did this by the help of help2man for the Debian distribution and upstream is free to take over these. (There is some kind of fixed phrase for Debian written manpages which you can look up in our SVN repository in several examples or at other places.) If you have done so feel free to ping me again for an upload. I could not find the fixed phrase you mention. However, I noticed that packages which rely on help2man like Velvet or Bowtie omit the [author] section in their manpages. I am now following their example for the Grinder package. I believe that this should address your issue. I also added a basic load test. Does one generally need to ping you for every upload, or is it generally sufficient to modify the changelog file from 'UNRELEASED' to 'unstable'? Best, Florent -- 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/4f222b63.1090...@gmail.com
Wishlist for the sprinters.
Hello everybody, I am recovering from a server crash and a grant application writing, so my mail box has one thousand unread emails… Luckily, this includes commit messages. I wish an excellent sprint meeting to everybody. It just came to my mind that I could try to make a wish in case some Java experts are around. We need snappy-java to be packaged in order to update picard-tools, which has some nice options that samtools does not have, like merging two FASTQ files in a single paire-end unaligned BAM file. Here are links my ITP and temporary package. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636181 http://anonscm.debian.org/gitweb/?p=users/plessy/snappy-java.git The problem that I do not manage to solve, is how to make snappy-java use Debian's packaged snappy library. http://lists.debian.org/debian-java/2011/11/msg8.html If it happens to be an easy problem for one of you, I would be really greatful if you could give it a try ! Cheers, -- Charles Plessy Debian Med packaging team http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20120127020738.gc11...@merveille.plessy.net
Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On Thu, Jan 26, 2012 at 02:19:51PM -0500, Bhaskar, K.S wrote: > >>>[KSB] Are there packages that are (for example) pure shell scripts > >>>so that there is no difference between a source package and a binary > >>>package? A VistA Debian package would be like that. > >>There are packages containing pure HTML pages (some doc packages) and > >>some packages might contain only some shell script (I do not know > >>examples but nothing in policy does forbid this.) > >Not to forget applications written in scripting languages. > >GNUmed packages do not contain any compiled code either > >(which, however, got nothing to do with whether you are > >looking at the source or the binary package). > [KSB] For packages such as GNUmed, are there separate source and > "binary" tarballs? No. It is written in a scripting language (Python) which compiles just-in-time. 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/20120126203055.gc2...@hermes.hilbert.loc
Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On Thu, Jan 26, 2012 at 02:19:51PM -0500, Bhaskar, K.S wrote: > [KSB] For packages such as GNUmed, are there separate source and > "binary" tarballs? There is no such thing like binary tarballs (at least not in the Debian universe). Moreover I doubt that such thing exists for Python projects because it is not needed for scripting languages. 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/20120126200029.gc18...@an3as.eu
Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On 01/26/2012 05:23 AM, Karsten Hilbert wrote: On Thu, Jan 26, 2012 at 08:10:13AM +0100, Andreas Tille wrote: [KSB] Are there packages that are (for example) pure shell scripts so that there is no difference between a source package and a binary package? A VistA Debian package would be like that. There are packages containing pure HTML pages (some doc packages) and some packages might contain only some shell script (I do not know examples but nothing in policy does forbid this.) Not to forget applications written in scripting languages. GNUmed packages do not contain any compiled code either (which, however, got nothing to do with whether you are looking at the source or the binary package). [KSB] For packages such as GNUmed, are there separate source and "binary" tarballs? Regards -- Bhaskar Karsten -- GT.M - Rock solid. Lightning fast. Secure. No compromises. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -- 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/4f21a757.9020...@fisglobal.com
Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On Thu, Jan 26, 2012 at 08:30:14PM +0100, Karsten Hilbert wrote: > So much the better. The Debian-resident VistA guru would > receive said email, review packages by "naive" Debian users I was to say: [...] review packages for fitness for consumption by "naive" Debian users [...] 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/20120126193252.gb2...@hermes.hilbert.loc
Re: [MoM] Packaging fis-get
Hi Luis, On Thu, Jan 26, 2012 at 11:16:52AM -0500, Luis Ibanez wrote: > > Then I called "debuild". > > (so my rule of thumb is that "debuild" must be called > from a directory that has the 'package name', in this > case "fis-gtm-initial" and that it expects the orig.tar.gz > file to be in the parent directory.) Yes, this rule of thumb works. :-) > Finished running lintian. > Now signing changes and any dsc files... > signfile fis-gtm-initial_54002B-1.dsc Andreas Tille > gpg: skipped "Andreas Tille ": secret key not available > gpg: /tmp/debsign.UEQdYnHe/fis-gtm-initial_54002B-1.dsc: clearsign failed: > secret key not available > debsign: gpg error occurred! Aborting > debuild: fatal error at line 1246: > running debsign failed > > > Which is good news. Yes. I think full quotes of such build logs do not need to be quoted any more (except in case of problems). > I verify that there is a .tar.gz file down > in the debian directory now. > > The command: > > find . -name "*.tar.gz" > > returns: > > ./gtm_V54002B_linux_i686_pro-i386.tar.gz > ./gtm_V54002B_linux_x8664_pro-amd64.tar.gz > ./debian/fis-gtm-initial/usr/lib/fis-gtm/distribution/gtm_V54002B_linux_i686_pro-i386.tar.gz Fine. > and I confirm that the command: > > make -f debian/rules clean > > cleans the "debian" directory. > > It essentially removes the files: > > debian/fis-gtm-initial/usr/lib > debian/fis-gtm-initial/usr/lib/fis-gtm > debian/fis-gtm-initial/usr/lib/fis-gtm/distribution > debian/fis-gtm-initial/usr/lib/fis-gtm/distribution/gtm_V54002B_linux_i686_pro-i386.tar.gz > debian/fis-gtm-initial/usr/share > debian/fis-gtm-initial/usr/share/fis-gtm-initial > debian/fis-gtm-initial/usr/share/fis-gtm-initial/defaults.template > debian/fis-gtm-initial/usr/share/doc > debian/fis-gtm-initial/usr/share/doc/fis-gtm-initial > debian/fis-gtm-initial/usr/share/doc/fis-gtm-initial/copyright > debian/fis-gtm-initial/usr/share/doc/fis-gtm-initial/changelog.Debian.gz > > > (this was verified by doing "find debian" before > and after doing "make -f debian/rules clean") Rule of thumb for the clean target: After make -f debian/rules clean the directory should be byte identical to the state before you called debuild. If not, you need to fix the clean target. > So, > It looks like I manage to replicate the > recipe and get the package to build. Yes. > This is REALLY helpful !:-) > > In retrospective, I should probably > have started with this one. Yes. Probably I should make a mental note for the next MoM student. > I'll reply to that one, in order > to keep the continuity of the > thread. As you see I'm back online after arriving here in Southport. Need to inspect some mail backlog and chat with people here. 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/20120126193055.ga18...@an3as.eu
Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On Thu, Jan 26, 2012 at 11:50:41AM -0500, Bhaskar, K.S wrote: > >Another approach would be to drop package management from > >BSD and make it rely on the host OS package management. > >Possible but not feasible, I fully agree. > [KSB] Let's take the analogy between VistA and a hosted virtual > machine a bit further. Suppose the virtual machine's root file > system was booted off a partition on the host using a copy-on-write > virtual disk, or NFS mounted, or via an iSCSI target. In that case, > it is possible to update virtual machines by making changes at the > host. But you cannot make all changes at the host - some changes > will need to be made within the virtual machines, and you have to > know what you are doing. Similarly, VistA is not an opaque blob. > You can make some changes at the host, but others will need to be > made within VistA, and it requires expertise to know what is correct. This confirms my current understanding of VistA. Good. > >So, what can an upgraded VistA package usefully do ? It can > > > >- make sure there's enough resources for the "next version" > [KSB] I am not sure if this relevant. There are always enough > resources, since the limits are the host filesystem and database. Exactly. It can make sure that the host filesystem and database and RAM and CPU provide sufficient resources to still run VistA after applying an upgrade. In the most basic sense it can check whether there's enough disk space for: - downloading recommended new/updated KIDS packages - unpacking them - installing them > >- provide external backup scripts > [KSB] This is easily done with simple shell scripts. Exactly. And those can be provided by (and delivered in improved form) the (regularly updated) Debian package. > >- serve as a reminder to less-inside VistA people telling > > us "VistA insider Bhaskar decided that now there's a > > useful/important/needed collection of KIDS packages > > available which you really should install" > >- helpfully download those KIDS packages into a local cache > > while I'm still busy doing something else > >- tell the VistA-blob/-VM on our machines the following: > > > > /usr/sbin/hey-vista-upgrade-yourself --from=here > > > > which could then run interactively and require my > > intervention as needed > > > >That would seem to me a useful level of integration already. > > > >But maybe this is a pipe dream for one reason or another. > [KSB] VistA already has infrastructure to send KIDS packages to > registered recipients via e-mail. So much the better. The Debian-resident VistA guru would receive said email, review packages by "naive" Debian users and "approve" them for inclusion in/recommendation by the next VistA package. This will - provide for Debian-smoothed installation of "approved" KIDS packages - tell Debian VistA users about "new" packages in a way they are used to > >A Debian package need not "take away" from what VistA > >already does or re-create functionality VistA already has. > >But it can provide glue and Debian-like access to VistA > >functionality. > [KSB] Agreed. We should let VistA do what it does and supplement it > where appropriate. That approach is IMO reasonable. > In my experience, the mechanics of installing VistA are > straightforward. Configuring VistA is a major project because it is > a complete ERP system for a hospital (it even has features for > managing inventory, for example). Over the years, one source of > disappointments that I have seen when people install VistA is the > realization that while installing VistA can be done in minutes, > getting it running even for a small practice takes expertise. That much I knew. That would be another possible source of Debian VistA packages: - vista-single-practice-template.deb - vista-multi-practice-template.deb - vista-hospital-basics.deb - vista-hospital-surgery.deb - vista-hospital-internal_med.deb ... Of course, even after installing *that* a lot of configuration will still need doing. But maybe such templates are already available inside VistA. Or perhaps the above should simply be scripts installed by vista.deb doing/invoking the appropriate VistA action. 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/20120126193014.ga2...@hermes.hilbert.loc
Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On 01/26/2012 05:19 AM, Karsten Hilbert wrote:
Hello Bhaskar,
this is a really helpful explanation. Let me rephrase (and
slightly change) it as to make sure we've understood:
You attest to that VistA is, basically, on big dark BLOB
sitting on the host OS which the host cannot know anything
about ("cannot" in the sense of "it is too hard to teach the
host about the innards of the VistA blob). That may well be
correct. You also attest, that, of course, a VistA package
can drop that BLOB into the system.
I assume the biggest difference between VistA-blob and
host-OS is that VistA never runs on the bare metal while the
host OS does (I'm sure there's one counter-example with some
obscure hardware out there). IOW, VistA "always" *requires*
a host to be present.
Perhaps it is an even better analogy to think of (in this
case) Debian as the host OS running on the bare metal and
VistaA being a VM living and running on top of that ?
For comparison, surely Debian does not know much about a
BSD-VM and sure as hell doesn't try to update software
inside it (let's ignore that BSD *could* run on the bare
metal).
In the following, replace "BSD" for "VistA":
Technically it would surely be *possible* to
- teach Debian about the tools it needs to run
on behalf of the BSD-VM to update that
- mount the BSD-VM
- run the BSD upgrader inside the BSD-VM
This may not be very *realistic*, however.
Another approach would be to drop package management from
BSD and make it rely on the host OS package management.
Possible but not feasible, I fully agree.
[KSB] Let's take the analogy between VistA and a hosted virtual machine a
bit further. Suppose the virtual machine's root file system was booted
off a partition on the host using a copy-on-write virtual disk, or NFS
mounted, or via an iSCSI target. In that case, it is possible to update
virtual machines by making changes at the host. But you cannot make all
changes at the host - some changes will need to be made within the
virtual machines, and you have to know what you are doing. Similarly,
VistA is not an opaque blob. You can make some changes at the host, but
others will need to be made within VistA, and it requires expertise to
know what is correct.
So, what can an upgraded VistA package usefully do ? It can
- make sure there's enough resources for the "next version"
[KSB] I am not sure if this relevant. There are always enough resources,
since the limits are the host filesystem and database.
- provide external backup scripts
[KSB] This is easily done with simple shell scripts.
- provide an improved tool to "create VistA environments"
on my machine
[SKB] Agreed. A VistA Debian package would be a better tool than my
current "SemiVivA" installation packages.
- serve as a reminder to less-inside VistA people telling
us "VistA insider Bhaskar decided that now there's a
useful/important/needed collection of KIDS packages
available which you really should install"
- helpfully download those KIDS packages into a local cache
while I'm still busy doing something else
- tell the VistA-blob/-VM on our machines the following:
/usr/sbin/hey-vista-upgrade-yourself --from=here
which could then run interactively and require my
intervention as needed
That would seem to me a useful level of integration already.
But maybe this is a pipe dream for one reason or another.
[KSB] VistA already has infrastructure to send KIDS packages to
registered recipients via e-mail. Of course, that is a push system,
whereas Debian package management is a pull system (with periodic polling
by the local package manager).
You can update each virtual machine with aptitude and Debian package
updates.
BSD hosting a Debian machine could well do the following
sequence when a new Debian has been released:
check-available-space
download-packages
mount-debian-vm
send-to-debian "update-yourself-and-here's-your-package-cache"
remove-package-cache
This, of course, requires at least some knowledge on what's
inside the VM blob.
after running aptitude. So, you must run aptitude on each virtual
machine individually: you can't run aptitude on your host and update
all your virtual machines in one fell swoop.
But you can run the above sequence on a bunch of VMs.
A Debian package need not "take away" from what VistA
already does or re-create functionality VistA already has.
But it can provide glue and Debian-like access to VistA
functionality.
[KSB] Agreed. We should let VistA do what it does and supplement it
where appropriate.
In my experience, the mechanics of installing VistA are straightforward.
Configuring VistA is a major project because it is a complete ERP system
for a hospital (it even has features for managing inventory, for
example). Over the years, one source of disappointments that I have seen
when people install VistA is the realization that while installing VistA
can be done in minutes, getting it running even for a sma
Re: [MoM] Packaging fis-get
On Wed, Jan 25, 2012 at 3:15 AM, Andreas Tille wrote: > > I would expect to find the content of the generated tar.gz files in > > the debian/ directory, not the tar.gz file itself. > > > > > This is because Thorsten decided to move the complete tarball straight > into the *.deb package which is a very untypical decision and I was > reasoning about this several times in this thread. So after a > >debuild > > it is correct to find a tarball in debian/ because this > is also in the *.deb. If you do a > >make -f debian/rules clean > > this should vanish and the debian/ dir should be as clean as before. > > Yes, I managed to confirm this. Now that I understand better the directory locations where commands must be typed, and the places where files are intended to go, I can reproduce the following recipe from scratch: cd debian-med/trunk/packages/fis-gtm/fis-gtm-initial/trunk make -f debian/rules get-orig-source Get the following output: . ./debian/get-orig-source check version of software -- Downloading updated package gtm_V54002B_linux_i686_pro.tar.gz Filename i386: gtm_V54002B_linux_i686_pro.tar.gz PKG: fis-gtm-initial PKGVERSION: 54002B architecture: i386 -- Downloading updated package gtm_V54002B_linux_x8664_pro.tar.gz Filename i386: gtm_V54002B_linux_x8664_pro.tar.gz PKG: fis-gtm-initial PKGVERSION: 54002B architecture: amd64 This brought the file: fis-gtm-initial_54002B.orig.tar.gz to the parent directory: debian-med/trunk/packages/fis-gtm/fis-gtm-initial which is verified by typing "ls .." that returns: fis-gtm-initial_54002B.orig.tar.gz trunk then I go to the parent directory: cd .. where "pwd" returns: debian-med/trunk/packages/fis-gtm/fis-gtm-initial (BTW, in all "pwd"s results in this email, I'm removing the base text "/home/ibanez/src" since it is probably not relevant for the recipe). and expand the .orig.tar.gz file: tar -xzf *.orig.tar.gz this creates a "fis-gtm-initial" directory. I copy the "debian" directory into the new "fis-gtm-initial" directory: cp -a trunk/debian/ fis-gtm-initial and I cd into it: cd fis-gtm-initial/ at that point "ls" returns: debian gtm_V54002B_linux_i686_pro-i386.tar.gz gtm_V54002B_linux_x8664_pro-amd64.tar.gz and "ls .." returns: fis-gtm-initial fis-gtm-initial_54002B.orig.tar.gz trunk Then I called "debuild". (so my rule of thumb is that "debuild" must be called from a directory that has the 'package name', in this case "fis-gtm-initial" and that it expects the orig.tar.gz file to be in the parent directory.) the output of "debuild" is: dpkg-buildpackage -rfakeroot -D -us -uc dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: source package fis-gtm-initial dpkg-buildpackage: source version 54002B-1 dpkg-buildpackage: source changed by Andreas Tille dpkg-source --before-build fis-gtm-initial dpkg-buildpackage: host architecture i386 fakeroot debian/rules clean dh clean dh_testdir debian/rules override_dh_auto_clean make[1]: Entering directory `/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm-initial/fis-gtm-initial' dh_auto_clean rm -f debian/defaults.template make[1]: Leaving directory `/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm-initial/fis-gtm-initial' dh_clean dpkg-source -b fis-gtm-initial dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building fis-gtm-initial using existing ./fis-gtm-initial_54002B.orig.tar.gz dpkg-source: info: building fis-gtm-initial in fis-gtm-initial_54002B-1.debian.tar.gz dpkg-source: info: building fis-gtm-initial in fis-gtm-initial_54002B-1.dsc debian/rules build dh build dh_testdir debian/rules override_dh_auto_configure make[1]: Entering directory `/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm-initial/fis-gtm-initial' echo "do not configure anything in this step" do not configure anything in this step make[1]: Leaving directory `/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm-initial/fis-gtm-initial' dh_auto_build dh_auto_test fakeroot debian/rules binary dh binary dh_testroot dh_prep dh_installdirs debian/rules override_dh_auto_install make[1]: Entering directory `/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm-initial/fis-gtm-initial' # that's a pretty complex way to copy the gtm tarball to a certain dir - let's rather do this directly # cat debian/install.template > debian/install # echo "/usr/lib/fis-gtm" >> debian/install mkdir -p debian/fis-gtm-initial//usr/lib/fis-gtm/distribution # Considering that there are two distinct tarballs in the origina
Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On Wed, Jan 25, 2012 at 06:13:36PM -0500, Bhaskar, K.S wrote: > >Hmmm, just to make sure I understood everything correctly let me assume > >we want to remove a VistA package at some point in time but keep the > >data it created. Dpkg expects to find all those files it has installed > >in certain places to remove them (as it has installed them before). > >What will now happen to your data. Will these hang around in those > >directories which previosely were installed by the packages. While we > >can deel with everything somehow this means extra work^Wfun for the > >packager. > > [KSB] You can't properly separate VistA from the data. On another > message I posted to this thread a few minutes ago, I made an analogy > between a VistA environment and a Linux virtual machine. You can > think VistA environmenta just as you can think of virtual machines: > although you can delete a VistA environment completely, just as you > can delete a virtual machine, you can't keep the data in a VistA > environment and delete the VistA, just as you can't easily keep the > data in a virtual machine root partition and delete the rest of the > virtual machine. Oh, you could, by mounting the disk images and deleting all but the data files (which requires knowledge about what's inside the VM, yes). One could then, technically, re-inject the VM-OS into the data-only-VM-remnant at a later stage. But I agree this is rarely useful. More useful would be to extract the data files from the VM and keep them for injection into another VM. But that's a backup, not a separation. And it may well be "not possible" with a VistA-VM. So, sticking to the VistA-VM metaphor is likely going to help. 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/20120126102807.gd2...@hermes.hilbert.loc
Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On Thu, Jan 26, 2012 at 08:10:13AM +0100, Andreas Tille wrote: > > [KSB] Are there packages that are (for example) pure shell scripts > > so that there is no difference between a source package and a binary > > package? A VistA Debian package would be like that. > > There are packages containing pure HTML pages (some doc packages) and > some packages might contain only some shell script (I do not know > examples but nothing in policy does forbid this.) Not to forget applications written in scripting languages. GNUmed packages do not contain any compiled code either (which, however, got nothing to do with whether you are looking at the source or the binary package). 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/20120126102306.gc2...@hermes.hilbert.loc
Re: How Debian Packaging practices could apply to VistA maintenance and distribution
Hello Bhaskar,
this is a really helpful explanation. Let me rephrase (and
slightly change) it as to make sure we've understood:
You attest to that VistA is, basically, on big dark BLOB
sitting on the host OS which the host cannot know anything
about ("cannot" in the sense of "it is too hard to teach the
host about the innards of the VistA blob). That may well be
correct. You also attest, that, of course, a VistA package
can drop that BLOB into the system.
I assume the biggest difference between VistA-blob and
host-OS is that VistA never runs on the bare metal while the
host OS does (I'm sure there's one counter-example with some
obscure hardware out there). IOW, VistA "always" *requires*
a host to be present.
Perhaps it is an even better analogy to think of (in this
case) Debian as the host OS running on the bare metal and
VistaA being a VM living and running on top of that ?
For comparison, surely Debian does not know much about a
BSD-VM and sure as hell doesn't try to update software
inside it (let's ignore that BSD *could* run on the bare
metal).
In the following, replace "BSD" for "VistA":
Technically it would surely be *possible* to
- teach Debian about the tools it needs to run
on behalf of the BSD-VM to update that
- mount the BSD-VM
- run the BSD upgrader inside the BSD-VM
This may not be very *realistic*, however.
Another approach would be to drop package management from
BSD and make it rely on the host OS package management.
Possible but not feasible, I fully agree.
So, what can an upgraded VistA package usefully do ? It can
- make sure there's enough resources for the "next version"
- provide external backup scripts
- provide an improved tool to "create VistA environments"
on my machine
- serve as a reminder to less-inside VistA people telling
us "VistA insider Bhaskar decided that now there's a
useful/important/needed collection of KIDS packages
available which you really should install"
- helpfully download those KIDS packages into a local cache
while I'm still busy doing something else
- tell the VistA-blob/-VM on our machines the following:
/usr/sbin/hey-vista-upgrade-yourself --from=here
which could then run interactively and require my
intervention as needed
That would seem to me a useful level of integration already.
But maybe this is a pipe dream for one reason or another.
> You can update each virtual machine with aptitude and Debian package
> updates.
BSD hosting a Debian machine could well do the following
sequence when a new Debian has been released:
check-available-space
download-packages
mount-debian-vm
send-to-debian "update-yourself-and-here's-your-package-cache"
remove-package-cache
This, of course, requires at least some knowledge on what's
inside the VM blob.
> after running aptitude. So, you must run aptitude on each virtual
> machine individually: you can't run aptitude on your host and update
> all your virtual machines in one fell swoop.
But you can run the above sequence on a bunch of VMs.
A Debian package need not "take away" from what VistA
already does or re-create functionality VistA already has.
But it can provide glue and Debian-like access to VistA
functionality.
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/20120126101930.gb2...@hermes.hilbert.loc
Discovered seqanswers.com for me
Hello, this is a friendly community addressing issues in next generation sequencing http://seqanswers.com and there is a NAR paper on it http://nar.oxfordjournals.org/content/early/2011/11/15/nar.gkr1058.abstract I liked how they communicate in their forum. And it also rendered it very clear to me that I am not the one to help bringing all those new (or not so new) tools to our distribution that are discussed at length. We are lucky to have Tim and friends with Bio-Linux with us. But some daily routine with wet-lab vicinity would certainly help all of us. The best would be if any issue arising on seqanswers with Debian the community would rest assured to be fixed real quickly. Maybe there is someone, not necessarily with programming skills, who could help with communication between them and our list (and debian.org/bugs)? Better ideas? Many greetings Steffen -- 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/4f211e22.3000...@gmx.de
CTK current status (commontk)
Hi all,
I gave commontk another shot today. It fails with latest dcmtk 3.6.0:
/home/mathieu/debian/debian-med/trunk/packages/ctk/trunk/ctk-0.1.0~git20120125/Libs/DICOM/Core/ctkDcmSCU.cc:
In member function 'virtual OFCondition
ctkDcmSCU::sendECHORequest(T_ASC_PresentationContextID)':
/home/mathieu/debian/debian-med/trunk/packages/ctk/trunk/ctk-0.1.0~git20120125/Libs/DICOM/Core/ctkDcmSCU.cc:644:7:
error: 'DCM_dcmnetLogger' was not declared in this scope
/home/mathieu/debian/debian-med/trunk/packages/ctk/trunk/ctk-0.1.0~git20120125/Libs/DICOM/Core/ctkDcmSCU.cc:670:9:
error: 'DCM_dcmnetLogger' was not declared in this scope
/home/mathieu/debian/debian-med/trunk/packages/ctk/trunk/ctk-0.1.0~git20120125/Libs/DICOM/Core/ctkDcmSCU.cc:
In member function 'virtual OFCondition
ctkDcmSCU::sendSTORERequest(T_ASC_PresentationContextID, const
OFString&, DcmDataset*, Uint16&)':
and later on with vtk 5.8.0
/home/mathieu/debian/debian-med/trunk/packages/ctk/trunk/ctk-0.1.0~git20120125/Libs/Visualization/VTK/Core/vtkLightBoxRendererManager.cpp:
In member function 'void
{anonymous}::RenderWindowItem::SetupHighlightedBoxActor(const double*,
bool)':
/home/mathieu/debian/debian-med/trunk/packages/ctk/trunk/ctk-0.1.0~git20120125/Libs/Visualization/VTK/Core/vtkLightBoxRendererManager.cpp:188:19:
error: 'class vtkPolyDataMapper2D' has no member named
'SetTransformCoordinateUseDouble'
make[2]:
[Libs/Visualization/VTK/Core/CMakeFiles/CTKVisualizationVTKCore.dir/vtkLightBoxRendererManager.cpp.o]
Error 1 (ignored)
Linking CXX shared library ../../../../bin/libCTKVisualizationVTKCore.so
So I am stopping my effort on CTK until next version of VTK 5.8.x
comes out, as well as next version of dcmtk 3.6.x
Thanks for your understanding.
On Mon, Jan 9, 2012 at 9:58 AM, Mathieu Malaterre
wrote:
> Hi Andreas,
>
> Thanks again for the reminder. I can't seems to find time those last
> days. CTK has gone through a very large refactoring and API change, I
> need more time to close this bug properly.
>
> Take care and happy new year to you too !
>
> On Thu, Jan 5, 2012 at 12:30 PM, Andreas Tille wrote:
>> Ping?
>>
>> Happy new year
>>
>> Andreas.
>>
>> - Forwarded message from Andreas Tille -
>>
>> Date: Fri, 16 Dec 2011 12:27:30 +0100
>> From: Andreas Tille
>> To: 635...@bugs.debian.org, Mathieu Malaterre
>> Subject: Bug#635569: Pending upload
>> X-Debian-PR-Message: followup 635569
>> X-Debian-PR-Package: ctk
>> X-Debian-PR-Keywords:
>> X-Spam_score: -2.8
>>
>> Hi,
>>
>> there is a changelog in SVN saying
>>
>>
>> ctk (0.1.0~git2003-1) experimental; urgency=low
>>
>> ...
>> * Fix spelling in d/control. Closes: #635569
>> ...
>>
>> -- Mathieu Malaterre Sun, 04 Sep 2011
>> 14:53:54 +0200
>>
>>
>> but despite the fact that the target dist is not UNRELEASED the package
>> did not showed up in experimental. Mathieu, could you please either
>> upload (prefered) or at least mark the status of packaging correctly?
>>
>> Kind regards
>>
>> Andreas.
>>
>> --
>> http://fam-tille.de
>>
>>
>>
>> ___
>> Debian-med-packaging mailing list
>> debian-med-packag...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>>
>>
>> - End forwarded message -
>>
>> --
>> http://fam-tille.de
>
>
>
> --
> Mathieu
--
Mathieu
--
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+7wUszaTvT8w0+1vFzSpYT791u7Tqc0GnJ1jPxp=zz+nda...@mail.gmail.com
