Re: [MoM] Packaging fis-get
On 01/23/2012 03:09 AM, Andreas Tille wrote:
[KSB] These look like binary distributions. For what it's worth, the
GT.M distribution files have names of the form:
On Sun, Jan 22, 2012 at 06:12:34PM -0500, Luis Ibanez wrote:
The .tar.gz file is placed in the parent directory at:
Fine so far.
5) Expanded it with command:
tar -xzf *.orig.tar.gz
and now get two new files at:
<ver> is an abbreviated form of the version number, e.g., V54002B is
short for V5.4-002B
<os> is the operating system, in this case, linux
<arch> is the architecture, in this case i686 or x8664
<pkg> is can be "src", "pro", "bta" or "dbg"
Note that <os> and <arch> are names from GT.M, e.g., even though Debian
calls the 64 bit x86 architecture amd64, GT.M refers to it as x8664.
Also, "src" is a source distribution, and even though the source tarball
identifies itself as i686, the same source code builds both 32- and
64-bit binary distributions. "pro" is short for production, and the
normal binary distribution. "dbg" is a binary distribution for debugging
- it has asserts turned on, which means that under certain conditions
processes will terminate with an assert instead of running code to try to
recover from the internal inconsistency. "bta" is in between "pro" and
"dbg" but we don't use bta builds any more in the development group.
[KSB] GT.M has a compiler for the M/MUMPS language. The compiler takes
source code in .m files and generates object code in .o files. The GT.M
runtime system dynamically loads these .o files on demand in all
architectures. On the 64-bit architecture, the .o files can also be
placed in shared libraries with ld, but not on the 32-bit architecture.
Yes, this is correct. Please remind: This is a really far from normal
package. Having tar.gz files inside a Debian orig.tar.gz file is
possible (I'm sure the X packages formerly were packaged like this, to
lazy to check whether this is the case today - you can verify by
apt-get source xorg
if you are interested). So usually you will find unpacked source files.
At least this is what Thorsten previosely did. He seems to be on VAC
because he did not yet stepped into this discussion so we need to fight
our way to his decisions on our own. In case we would consider this as
not helpful in the end we can change whatever is needed.
inspected both with tar -tzf
and since none of them
is creating its own directory yet,
I created directories with their names.
The idea is not bad, but the packaging is intended to leave the files
as they are.
6) Created directories:
So this was a step which is not helpful for the current packaging.
However, once we are talking about those archives I have a question to
you with your upstream hat on: What is the sense to provide a lot of
*.o files inside these tarballs? As far as I know you need a running
mumps as an initial step and I see some binaries starting with mu*
inside the tarball. However, the *.o files are looking pretty useless
to me. If my suspicion that these are simply leftovers from compile
process and not really needed it would be helpful if these could be
stripped from the upstream tarball (perhaps in the same effort when
creating non-dirty directories).
A GT.M binary distribution contains some utility programs distributed as
source code (.m files) and the installation script (named configure)
compiles these as part of the installation process.
There are also binary files (GDE*.o files) whose source code is not
included in the binary distributions. This is because the GDE program
considered an executable program that is part of GT.M, except that it is
written in M and not in C, as the other executables are. Of course, all
source code is in the source tarball.
[KSB] Note that there are (at least!) two strategies to creating a GT.M
What we can do for the Debian orig.tar.gz when we are creating this
file anyway in the get-orig-source script is the following:
1. unpack the tarballs
2. remove *.o files (and other possibly unneeded binaries
3. move files which are *specific* for the different architectures
to directories named like bin-i386 resp. bin-amd64 (or something
4. move files which are common to both architectures to a directory
common (*.m, *.h, *.gtc, shell scripts, *.hlp, etc.)
BTW, I also found *.csh files: After inspecting some of these
they could be probably ported to POSIX shell which would enable
us sparing a useless csh (clone) dependency. There is no point
in forcing an unneeded shell as a dependency upon the user
If you consider this plan a good idea your task would be the following:
Change get-orig-source so that the resulting
fis-gtm-initial_54002B.orig.tar.gz will have the following layout:
fis-gtm-initial-+ (optional fis-gtm-initial-54002B at your preference)
By doing so we get a more transparent tarball. However, this leads to
the consequence that the current packaging which explicitely relies on
the complete tarballs need to be changed. You need to tweak the install
target as well as changing the postinst file. IMHO the postinst file
does to much work anyway as I wrote in my other mail tagged [MoM]
The first is to build a standard GT.M tarball, and to create a wrapper
for it. The wrapper would unpack the tarball in a temporary directory,
and run the configure script provided by GT.M to install the binary
distribution in standard locations. If you look at the gtminstall script
in the tarball (and separately at
it is an attempt to create such a wrapper. gtminstall is still a bit of
a work in process. This may be an easier approach.
The second is to create an installer that does not use the configure
script at all. This is a purer approach, but probably more work.
7) Entered the directory of the i386 version
and expanded in there the corresponding
.tar.gz file from the parent directory:
tar -xzf ../gtm_V54002B_linux_i686_pro-i386.tar.gz
8) Copy in this code the content of
the "debian" directory.
cp -a ../../trunk/debian/ .
9) Continued with Path (B) instructions
and called "debuild" in that same
typed the command:
that returned the message:
This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
(expected one of fis-gtm-initial_54002B.orig.tar.gz,
fis-gtm-initial_54002B.orig.tar.lzma or gtm_V54002B_linux_i686_pro-i386.orig)
continue anyway? (y/n) n
Considering your step 6) which I explained in detail steps 7) - 9) can
not succeed. I's advise to follow the original path of Thomas just for
the sake to get some kind of a deb first before fiddling around with
get-orig-source. You current directory layout after copying the debian/
dir should look like this:
$ ls -l fis-gtm-initial
drwxr-sr-x 4 tillea admin 4096 Jan 22 22:57 debian
-rw-r--r-- 1 tillea admin 10024159 Jan 22 14:58 gtm_V54002B_linux_i686_pro-i386.tar.gz
-rw-r--r-- 1 tillea admin 10251995 Jan 22 14:58 gtm_V54002B_linux_x8664_pro-amd64.tar.gz
10) Now go back to instructions on how to
fix the name of the expected version by
and attempt to do "debuild" again.
This time I get:
dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value:
dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package fis-gtm-initial
dpkg-buildpackage: source version 54002B-1
dpkg-buildpackage: source changed by Andreas Tille<email@example.com>
dpkg-buildpackage: host architecture amd64
dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 8)
dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: warning: (Use -d flag to override.)
debuild: fatal error at line 1340:
dpkg-buildpackage -rfakeroot -D -us -uc failed
That looks more promising... :-)
Yes. :-) Dominique just answered your question (nice to see that others
read your mails as well - you see the profit of writing to the mailing
It seems to be lacking "debhelper"
(I'm doing all this in a Ubuntu 10.04 LTS - Lucid Lynx )
Since "debuild" claims to need version>= 8,
it looks like it is time to try the same sequence
of steps in a more recent installation.
As Dominique said you either can simply step back in the debhelper
version. Alternatively it might be that there might be a backported
debhelper 8 available - I'm sorry, I never used Ubuntu and are just wild
guessing. Whether it is a good idea to keep on testing on Ubuntu or not
is hard to say. For the final upload you need a Debian unstable chroot
anyway so becoming comfortable with this is heavily recommended.
However, it might make sense to some extend to redo all your steps under
your target system (whatever it might be). Reducing the number of
dependencies (for instance getting rid of csh files of possible) might
make live easier.
I'm no heading to boot a VM
where I recently installed Ubuntu 11...
This does have debhelper 8, right? As I said: I personally can not help
much if it comes to Ubuntu specific problems. I hope these will be not
to many, but you might face situations when you need to ask for help at
other places. It would be great to have a result which builds unchanged
on Debian as well as on Ubuntu.
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.