Re: Seeking machines for nightly builds of ITK
On Tue, Aug 03, 2010 at 01:19:12AM -0500, Steve M. Robbins wrote: > If you have a non-amd64 machine with spare cycles each night that you > can either set up a build [2] or let me log in to do it, please reply. We have a sponsored machine which is hosting debian-med.debian.net. It is running an UDD instance and I'm testing all the Blends web pages stuff there. This consumes some cycles on the not to strong but for the moment sufficient machine. I'd say we could simply try if it can also bear the ITK builds. If there is no better offer just tell me your prefered login name and I will grant you the needed permissions on this machine. 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/20100803071732.gc2...@an3as.eu
Re: Connecting those interested in getting GT.M into the Debian repositories
Hi Bhaskar,
in the end you suggested to move this discussion to the Debian Med list
- I simply decided that it is time to do so now (and hope you will not
mind the full quote of a mail I can not find private content in).
On Tue, Aug 03, 2010 at 11:00:22AM -0400, K.S. Bhaskar wrote:
> The primary purpose of this e-mail is to connect those interested in
> getting GT.M into the Debian repositories. It is clear that if we wait
> for me to do it, it will tax the patience of all.
>
> * Andreas Tille is one of the movers and shakers of Debian Med and
> has been interested for years in getting GT.M packages into the
> Debian repositories.
> * Alan has expressed willingness to lead the effort. Andreas has
> expressed interest in providing guidance from the Debian perspective.
> * Jon Tai and Mike Clayton have built Debian packages from GT.M
> source tarballs released at Source Forge by FIS. Source Forge
> would be the upstream source for GT.M in the Debian repositories
> and FIS would be the upstream developers. I hope Jon & Alan can
> assist Alan with building GT.M (at least with advice).
> * Ignacio has created GT.M Debian packages from the binary tarballs
> released at Source Forge by FIS, but I think his interest is
> primarily in being a user of a GT.M Debian package for his
> Astronaut VistA rather than a builder of one. (Ignacio is also
> interested in Fedora rpms, but we won't go there in this discussion!)
Good summary.
> Here are some thoughts on the high level structure.
>
> * The package name for GT.M should (I think) be fis-gtm.
OK
> * Perhaps packages should be numbered such as
> fis-gtm_5.4-001A-3+lenny2_amd64.deb where 5.4-001A is the GT.M
> version, 3 is the third package of GT.M V5.4-001A, and it is built
> with the lenny2 toolchain for the amd64 architecture.
We need to target for unstable first and thus using lenny toolchain
doese not make any sense IMHO. Moreover my estimation is that we will
not finalise GT.M packages before Squeeze will be released - so
targeting at current unstable makes perfectly sense to me. Whether we
will be able to provide backports for stable distributions will turn
out later (probably reaslonable but increases the level of complexity
by one because of the bootstraping nature of GT.M build process).
> * Releases of GT.M should go into sub-directories of /usr/lib/fis-gtm.
Yes (except if there are large chunks of architecture independant data.
Than it should probably be a mix of /usr/lib/fis-gtm and /usr/share/fis-gtm
(symlinks to have all in /usr/lib are fine).
> * update-alternatives should be used to maintain multiple versions
> of GT.M on the system. I don't fully understand how this is
> configured. Perhaps fis-gtm itself should be a virtual package
> that always installs the latest GT.M on the system. /usr/bin/gtm
> could be a symbolic link (perhaps via /etc/alternatives) to
> /usr/lib/fis-gtm//gtm.
I do not know gtm enough to give an educated answer on this but starting
with /usr/lib/fis-gtm//gtm (perhaps without the final gtm
because it somehow seems to be redundant) seems to make sense anyway in
case you would like to run different versions at the same time. I'd
recommend adopting the scheme of postgresql
/usr/lib/postgresql//{bin,lib}
which uses a script
/usr/share/postgresql-common/pg_wrapper
to organise things. It turned out to be useful to have such working
examples in mind.
> * Also, perhaps mumps should be a virtual package that installs
> fis-gtm, but could allow for other FOSS MUMPS packages in the
> future (they do exist; they're just not as mature as GT.M). Thus
> /usr/bin/mumps could be a symbolic link through /etc/alternatives
> to /usr/bin/fis-gtm.
The correct wording is: fis-gtm *Provides: mumps* (as well as other
potential FOSS MUMPS implementations). (A virtual package does not
install anything but is provided by real packages. Other packages
which depend from any mumps implementation would then
Depends: mumps | fis-gtm )
However, as far as we only have this single mumps implementation I
do not see any need to make things more complicated than needed for
the moment.
> We do have a potential issue with bootstrapping GT.M on alioth, the
> Debian build system. Building GT.M requires an executable GT.M for
> bootstrapping (the way that compiling gcc requires an existing gcc).
> So, it seems to me that we have to create a binary GT.M packages first,
> get them installed on alioth and then use the source package to build
> more binary packages.
We do not necessarily do this on alioth (I guess alioth admins will not
be keen on giving us root permissions). IMHO we can do the installation
on any local build machine and try to build the package. Than we have
to talk to ftpmaster how to precisely proceed.
> Note that GT.M has
Re: Connecting those interested in getting GT.M into the Debianrepositories
Comments below. Look for [KSB].
Andreas, I took your name off the addressee list to avoid duplication.
Alan, Jon and Mike, let me know if you want me to leave your names off.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
On 08/03/2010 02:11 PM, Andreas Tille wrote:
Hi Bhaskar,
in the end you suggested to move this discussion to the Debian Med list
- I simply decided that it is time to do so now (and hope you will not
mind the full quote of a mail I can not find private content in).
[KSB] That's fine. Thanks.
On Tue, Aug 03, 2010 at 11:00:22AM -0400, K.S. Bhaskar wrote:
[KSB] <...snip...>
> * Perhaps packages should be numbered such as
> fis-gtm_5.4-001A-3+lenny2_amd64.deb where 5.4-001A is the GT.M
> version, 3 is the third package of GT.M V5.4-001A, and it is built
> with the lenny2 toolchain for the amd64 architecture.
We need to target for unstable first and thus using lenny toolchain
doese not make any sense IMHO. Moreover my estimation is that we will
not finalise GT.M packages before Squeeze will be released - so
targeting at current unstable makes perfectly sense to me. Whether we
will be able to provide backports for stable distributions will turn
out later (probably reaslonable but increases the level of complexity
by one because of the bootstraping nature of GT.M build process).
[KSB] I agree that we should target Unstable first. Note that the
bootstrap requires a release of GT.M, not the current release of GT.M
(again like gcc bootstrapping - you can use an old release of gcc to
compile a new release of gcc).
> * Releases of GT.M should go into sub-directories of /usr/lib/fis-gtm.
Yes (except if there are large chunks of architecture independant data.
Than it should probably be a mix of /usr/lib/fis-gtm and /usr/share/fis-gtm
(symlinks to have all in /usr/lib are fine).
[KSB] The only architecture dependent data are binary files compiled for
the target architecture. So, we don't need anything in /usr/share/fis-gtm.
At some point when we create an fis-gtm-doc package for the user
documentation, that can go in /usr/share/doc/fis-gtm.
> * update-alternatives should be used to maintain multiple versions
> of GT.M on the system. I don't fully understand how this is
> configured. Perhaps fis-gtm itself should be a virtual package
> that always installs the latest GT.M on the system. /usr/bin/gtm
> could be a symbolic link (perhaps via /etc/alternatives) to
> /usr/lib/fis-gtm//gtm.
I do not know gtm enough to give an educated answer on this but starting
with /usr/lib/fis-gtm//gtm (perhaps without the final gtm
because it somehow seems to be redundant) seems to make sense anyway in
case you would like to run different versions at the same time. I'd
recommend adopting the scheme of postgresql
/usr/lib/postgresql//{bin,lib}
which uses a script
/usr/share/postgresql-common/pg_wrapper
to organise things. It turned out to be useful to have such working
examples in mind.
[KSB] Actually, /usr/lib/fis-gtm//gtm is a shell script that you
can run to execute GT.M, and /usr/lib/fis-gtm/ is the directory
that contains the entire release. The actual executable binary file is
called mumps. There are other binaries as well, the most important of
which are mupip, dse and lke.
Now that I think of it, there is a file that can be sourced to set up
environment variables /usr/lib/fis-gtm//gtmprofile. Perhaps
there should be a directory /etc/fis-gtm//gtmprofile which is a
relative symbolic link to /usr/lib/fis-gtm//gtmprofile.
> * Also, perhaps mumps should be a virtual package that installs
> fis-gtm, but could allow for other FOSS MUMPS packages in the
> future (they do exist; they're just not as mature as GT.M). Thus
> /usr/bin/mumps could be a symbolic link through /etc/alternatives
> to /usr/bin/fis-gtm.
The correct wording is: fis-gtm *Provides: mumps* (as well as other
potential FOSS MUMPS implementations). (A virtual package does not
install anything but is provided by real packages. Other packages
which depend from any mumps implementation would then
Depends: mumps | fis-gtm )
However, as far as we only have this single mumps implementation I
do not see any need to make things more complicated than needed for
the moment.
[KSB] OK
> We do have a potential issue with bootstrapping GT.M on alioth, the
> Debian build system. Building GT.M requires an executable GT.M for
> bootstrapping (the way that compiling gcc requires an existing gcc).
> So, it seems to me that we have to create a binary GT.M packages first,
> get them installed on alioth and then use the source package to build
> more binary packages.
We do not necessarily do this on alioth (I guess alioth admins will not
be keen on giving us root permissions). IMHO we can do the installation
on any local build machine and try to build the package. Than we have
to talk to ftpmaster how to precisely proceed.
[KSB] OK
> Note that GT.M has a
What to do with draft packages?
Dear all, Sometimes I prepare a package locally, but never finish it for upload to Debian because I am unsure if I want to maintain it (I am Uploader of ~80 packages, and I have the impression that I am reaching a limit), and I also do not have the time to do the polishing correctly (nice description, debian/copyright, doc-base, regression tests, buildability twice in a row, lintian…). Also, the software may have a quite narrow scope, and the reason for packaging it locally is mostly to have an easy way to deinstall it or reinstall it if I switch computer. Sometimes, I stop using the program completely after finding an alternative that better fits my needs. This said, other people may be intersted in the draft packages, or even volunteer to finish them, so I wonder how much it would make sense to share them in a places such as ssh://git.debian.org/git/debian-med/drafts or svn://svn.debian.org/svn/debian-med/trunk/packages/drafts. What is your opinion ? -- 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/20100804043122.gb20...@merveille.plessy.net
