It looks like my e-mails to the group are still not getting through
debian-med. I sent this a half hour ago. Thank you very much in
advance for your help.
Regards
-- Bhaskar
-------- Original Message --------
On 07/21/2011 09:52 AM, Andreas Tille wrote:
Hi Thorsten,
On Wed, Jul 20, 2011 at 07:52:50PM +0200, Thorsten Alteholz
wrote:
> Hi everybody,
>
> it should be possible to build three packages for fis-gtm
now. One is
> just a meta-package, one is a package with the initial
(precompiled)
> software and one is a package that allows the binaries to
be built from
> source.
> If anybody wants to have a look, I would be happy to get
some feedback.
thanks for working on this. I made some very minor nitpicking
changes
in SVN. For the packaging itself I wonder if there is really
a need for
asking for a user and group name for the fisgtm user. I'd say
this is
not common (apache uses www-data, postgresql is using postgres
both
without asking the user for a name. If you really think that
this makes
sense I would make the question lower priority so that normal
users
will simply go with the default name.
[KSB] GT.M does not need a default user or group. Some user &
group need to own the installation files, but that can be root &
root (historically bin & bin). It is certainly possible to
configure a GT.M installation so that it is usable only by members
of a specific group, but that would be under special circumstances
(perhaps an additional layer of defense in an explicitly locked down
production server with real financial data or health records). For
normal usage, GT.M does not need a special user or group.
Then I tried to build the fis-gtm-initial-i386 package on an
amd64
system (I was sitting in the train to DebCOnf and was offline)
and
perhaps this is the problem - but the install failed (sorry
for
German locale but Thorsten will cope with it)
---------------------------------------------------------
$ sudo dpkg -i fis-gtm-initial-i386_54002A-1_amd64.deb
Vormals abgewähltes Paket fis-gtm-initial-i386 wird gewählt.
(Lese Datenbank ... 300570 Dateien und Verzeichnisse sind
derzeit installiert.)
Entpacken von fis-gtm-initial-i386 (aus
fis-gtm-initial-i386_54002A-1_amd64.deb) ...
fis-gtm-initial-i386 (54002A-1) wird eingerichtet ...
Creating config file /etc/default/fis-gtm-initial with new
version
Warnung: Auf das von Ihnen angegebene Home-Verzeichnis
/usr/share/fis-gtm kann nicht zugegriffen werden: Datei oder
Verzeichnis nicht gefunden
Lege Systembenutzer »fisgtm« (UID 110) an ...
Lege neuen Benutzer »fisgtm« (UID 110) mit Gruppe »fisgtm« an
...
Erstelle Home-Verzeichnis »/usr/share/fis-gtm« nicht.
##############################################
automatic configuration, please be patient ...
./configure: 109: ./geteuid: not found
[KSB] geteuid is an executable that is built as part of GT.M. If
you were trying to install a 32-bit GT.M on a 64-bit Linux, did you
have the 32-bit libraries installed? What does "file geteuid" say?
You must run Configure as root.
[KSB] This error is from the installation script's inability to run
geteuid.
... automatic configuration finished
##############################################
rmdir: konnte „TMPPOSTINST“ nicht entfernen: Das Verzeichnis
ist nicht leer
dpkg: Fehler beim Bearbeiten von fis-gtm-initial-i386
(--install):
Unterprozess installiertes post-installation-Skript gab den
Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
fis-gtm-initial-i386
-------------------------------------------------------
Besides this install failure I see the following issues where
I'm
admittedly to unexperienced with to give some reasonable
advise:
- Because of building on an amd64 machine the package ends up
with
"_amd64.deb" extension. While I think building on amd64
should
not necessarily be forbidden (it's just moving files into a
deb)
the result should be "_i386.deb"
[KSB] If you compiled GT.M using the instructions in the README in
the source tarball, it will build either a 32- or 64-bit executable,
depending on the host. There is an environment variable that can be
used to build a 32-bit executable on a 64-bit host (but not the
other way around).
This would probably prevent dpkg from trying
to install it on
amd64 machines.
- I also consider the "Architecture: any" in debian/control
as not
appropriate. If I'm not missleaded it should rather be
i386.
However, if I do this on my amd64 machine the package does
not
build (which makes sense for sure)
I have no real clue how to fix this. It might be an idea if
we
provide both (i386 and amd64) initial tarballs in one source
tarball
and let the rules file detect which one to use depending from
the
architecture the package is builded on.
[KSB] Our upstream distribution builds both 32- and 64-bit (x86)
executables from the same source tarball.
Regards
-- Bhaskar
What do you think? Perhaps discussing this issue on a more
general
list than Debian Med makes sense.
Kind regards from Banja Luka (just arrived)
Andreas
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-med-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] 20110721135204.GA7025@an3as.eu">http://lists.debian.org/[🔎] 20110721135204.GA7025@an3as.eu
--
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.
_____________