Maemo Development
"One man kebabbed, hundreds scarred forever by a shared blood
ritual. And yet, an astonishing sense of community here now,
a positive atmosphere, a sense of a job well done, a shared
sigh of relief - very much like the bizarre euphoria at the
end of an hour's vomiting."
This log records what I did to get my Maemo packages built. I
thought it would be a weekend's work. It was actually over a
week, and not a fun week either.
What was the point? I had three Debian packages I wanted
ported: Emacs, Clisp, and any IMAP server. They waxed and waned
in importance over the week, and at the end of the day only the
last one actually worked. That's what I choose to call
"success".
The log is stream of consciousness, blow-by-blow, and frequently
includes the exact commands I ran and the exact output that was
generated. Since I tend to multitask, and frequently give up on
packages and then revisit them later, it will be very confusing.
But I don't have time to write the novel.
Hopefully this will make useful google fodder: if your error
message is in here somewhere, there's a chance this will help
you fix it. If you're trying to build package "foo", best to
start at the end and search backwards for the last mention of
"foo". That way you'll avoid all my wrong turns.
I am a peaceful, easy-going kind of person. Apart, that is,
from when I'm trying to make software work. This log contains
swearing, and general railing against people whose only
crime was making software available to me for free. I've edited
out some of this, but not all. Software is supposed to just
work. Here, it didn't. Note that although it starts out kinda
scary, things settle down a bit later on.
I'm not going to enjoy it, but I'm going to dive into building
Maemo stuff. Here's
the tutorial. The development environment install
file. And now it starts. Just why does
this have to be done as root? The mind boggles. Oh well, at
least it apparently uses nice Debian packages if you happen to
be running debian.
Right, so I did that, and added myself with:
aeon:~# /scratchbox/sbin/sbox_adduser mexon yes
But before I can go any further, I have to log out of Gnome and
log back in again. That's a pain.
I'm going. It's all very confusing. I went through the menu
thing, and it asked me a bunch of questions I didn't understand,
but I'm just going to live with that. Now I'm picking up again
at installing the SDK. And apt-get update didn't work at all.
And this seemed to cause the fakeroot command to fail. So
generally, what the fuck? Why is this not even remotely
working? And why don't the instructions match reality? Why are
the instructions spread all over the place and appear completely
incompatible?
As far as I can see, I'm in some kind of sandbox, but it doesn't
have any internet access at all. It has some development tools,
including cc. So I'm removing, as root,
/scratchbox/users/mexon, and I'll try again. What else can I
do? Fuck, this is frustrating. The problem when a company like
Nokia decides to use an existing system like scratchbox is that
there is immediately nowhere to go for documentation. Any
documentation written by the scratchbox people is too
untrustworthy to use. Documentation is instantaenously reduced
to zero, like magic.
Man, I can't even remove it! Even as root! For fuck's sake,
you promised not to take over my machine, and here you are,
shitting all over the fucking thing and I can't get rid of you!
Fuck off!
I'm purging all the packages I can find. But fucking hell, this
isn't supposed to be like this. No, I can't get rid of
/scratchbox by any means whatsoever.
OK. The key thing was that a whole pile of stuff was mounted.
Unmount the filesystems, sometimes with -f, and it all goes
away. Good. But fuck me, why on earth doesn't apt unmount this
stuff for me? This is fucking evil.
So we're going again:
aeon:~# sh maemo-scratchbox-install_4.0.sh
Yes, I remember the part that fucked me up: "Specify users to be
added to scratchbox users with '-u USER' option." What, after
you already told me not to do that? Why didn't you
include that in the original instruction, you
bastard? But when I actually install, I get told this:
Installation was successful!
----------------------------
You now have Scratchbox 1.0.8 'apophis' release installed.
Scratchbox cannot be run as user root. Instead, use your normal login
user account. Add additional scratchbox users and sandboxes with the
following command (outside scratchbox with root permissions):
# /scratchbox/sbin/sbox_adduser USER yes
Running this command will create sandbox environment for that user and
add user to the 'sbox' scratchbox user group.
You will need to start a new login terminal after being added to the
'sbox' group for group membership to be effective.
Login to scratchbox session using the following command (as user):
$ /scratchbox/login
Refer to scratchbox.org documentation for more information re scratchbox:
http://scratchbox.org/documentation/user/scratchbox-1.0/
So already I have two things telling me completely opposite
instructions. What the hell am I meant to do? I ran that
sbox_adduser thing, but that seems to be the wrong thing to do.
Do I run the install script again now, but with a -u option?
aeon:~# sh maemo-scratchbox-install_4.0.sh -u mexon
...
Scratchbox installation not existing... no
E: Scratchbox already found in installation path '/scratchbox'.
E: Please remove your scratchbox installation first if you want to proceed.
E: Remember to copy your scratchbox users' home directories.
E: Also run '/scratchbox/sbin/sbox_ctl stop' before removing directory.
E: Specify an alternative installation path using '-s PATH' option.
Oh, fuck you!
See, the problem is that if you go through that INSTALL.txt
file, you end up being told "You can upgrade to maemo 4.0 just
by running issuing following commands inside the Scratchbox:".
But it doesn't tell you how to get inside scratchbox. So fuck
it, I'm going to run the commands on the screen.
Oh, by the way, I just fucked everything up by accidentally
removing all my device nodes when I was trying to remove the
scratchbox environment. Great, nice job guys, outstanding.
OK, a reboot. You know what's evil? Having an "sbox_adduser"
script but not bothering to include a "sbox_deluser" script.
Whoever built this thing clearly didn't care even slightly about
producing a quality product. This is a problem, because the
whole thing is so absurdly fragile, it can't recover from this
situation:
aeon:~# /scratchbox/sbin/sbox_adduser mexon yes
Scratchbox user account for user mexon already exists!
mexon@aeon:~$ /scratchbox/login
ln: creating symbolic link `/scratchbox/users/mexon/home/mexon/.terminfo' to `/scratchbox/etc/terminfo': No such file or directory
You dont have active target in scratchbox chroot.
Please create one by running "sb-menu" before continuing
Welcome to Scratchbox, the cross-compilation toolkit!
Use 'sb-menu' to change your compilation target.
See /scratchbox/doc/ for documentation.
bash: cd: /home/mexon: No such file or directory
sb-conf: No current target
[sbox-: /] >
So, again:
aeon:~# umount -f /scratchbox/users/mexon/scratchbox /scratchbox/users/mexon/tmp /scratchbox/users/mexon/proc /scratchbox/users/mexon/dev /scratchbox/users/mexon/dev/pts /scratchbox/users/mexon/dev/shm /scratchbox/users/mexon/sys
aeon:~# rm -rf /scratchbox/users/mexon
aeon:~# /scratchbox/sbin/sbox_adduser mexon yes
The user `mexon' is already a member of `sbox'.
Scratchbox user account for user mexon added
mexon@aeon:~$ /scratchbox/login
You dont have active target in scratchbox chroot.
Please create one by running "sb-menu" before continuing
Welcome to Scratchbox, the cross-compilation toolkit!
Use 'sb-menu' to change your compilation target.
See /scratchbox/doc/ for documentation.
sb-conf: No current target
I guess that's better. Now what? I ran sb-menu last time, and
wound up neck-deep in shit. But I certainly can't follow the
INSTALL.txt instructions:
[sbox-: ~] > apt-get update
bash: apt-get: command not found
sb-conf: No current target
Ah, wait, I get it. sb-menu is part of "Installing Maemo 4.0
SDK manually":
Generally, you do not need to do a manual install unless the
maemo SDK installer script cannot function in your specific
environment.
In other words, you really really really do need to
supply that fucking -u option right at the very, very start of
this whole fucking mess. So back to uninstalling everything all
over again.
aeon:~# sh maemo-scratchbox-install_4.0.sh -u mexon
So you can see what's happened. Someone built a bunch of
scratchbox .deb packages. And whoever that was, they were
fucking incompetent, because they added a gigantic pile of
unnecessary technical questions that no-one would ever know the
answer to. So then Nokia got their hands on this. They noticed
the buggering clusterfuck that was the scratchbox .deb packages,
and knew they had to fix it. But they didn't actually fix the
packages. Instead, they wallpapered over the whole thing by
writing a horrible hacky script to answer the stupid fucking
questions that should never have been asked in the first place.
Just so that we're all on the same page, this company expects me
to write software for free so that they can sell funky little
boxes at €430 a pop.
Right, so installation was allegedly successful again. Let's
take the hateful thing at its word:
mexon@aeon:~$ /scratchbox/login
You dont have active target in scratchbox chroot.
Please create one by running "sb-menu" before continuing
Welcome to Scratchbox, the cross-compilation toolkit!
Use 'sb-menu' to change your compilation target.
See /scratchbox/doc/ for documentation.
sb-conf: No current target
[sbox-: ~] > apt-get update
bash: apt-get: command not found
sb-conf: No current target
[sbox-: ~] >
Oh, gee, look, exactly where I fucking was before.
OK, how about this? Notice that I still have not the faintest
fucking clue whether I'm supposed to be using ARMEL or X86.
[sbox-: ~] > sb-conf setup CHINOOK_ARMEL -c cs2005q3.2-glibc2.5-arm -d perl:debian-etch:maemo3-tools:cputransp -t qemu-arm-0.8.2-sb2
sb-conf: No current target
Oh, wait, the quickstart instructions are telling me to do
something completely different. Which also doesn't work.
[sbox-: ~] > sb-conf select CHINOOK_X86
sb-conf: No such target: CHINOOK_X86
sb-conf: No current target
Fuck me, the next bit in the quickstart is writing "hello
world". I am so, so, so far away from being able to write
"hello world". "Hello world" is like some fantastic impossible
dream.
So wait, what about this
page? Is that now four separate documents all claiming to
be the One True Installation Instructions? Note the big yellow
warning:
N.B. IMPORTANT ! : Always refer to the INSTALL.txt file that
is delivered with maemo 4.0 release, and follow the
instructions in it. The INSTALL.txt file always contains the
most up-to-date information on how to install the release. For
this reason, the installation instructions have been removed
from this tutorial.
So where the flying fuck is it? I mean, there's a
link, but how can I trust that that's up-to-date? Because fuck
knows nothing else is.
aeon:/usr/share/doc# ls *scratch*/*INSTALL*
ls: *scratch*/*INSTALL*: No such file or directory
OK, so we're going to go with the instructions here.
I have no idea why Nokia's stuff is refusing to do anything
useful, but obviously I'm going to have to resort to the
scratchbox people's documentation. At least it has some
screenshots. And let's say we're trying to make X86 stuff,
although it would have been nice to get some guidance on this
from, like, someone.
No, no, that's no good. The screenshots don't show what's on my
screen. They've got "HOST host-gcc", but I've got
"CHINOOK_ARMEL cs2005q3.2-glibc2.5-arm". Do I really
want to create a new target? What is a "target"?
OK, so instead I'm just installing files to a target, and
choosing the existing one. I've gone for C-library, /etc,
Devkits, and fakeroot.
I'm really skim-reading the documentation for scratchbox, since
it's already departed from what I'm seeing. It seems to confirm
that I shouldn't install a rootstrap, which is looking scary and
I don't want to do, so I'm backing out of that. Next step I
guess is "Select".
Ah, now this is fascinating. My prompt has changed:
Shell restarting...
[sbox-CHINOOK_ARMEL: ~] >
Over in INSTALL.txt, it expects me to look like this:
[sbox-SDK_BETA_X86: ~] apt-get update
[sbox-SDK_BETA_X86: ~] fakeroot apt-get dist-upgrade
So something is wrong here.
Ah, wait, the above was for the upgrade, which always appears
first for some fucking reason. Later on, it tells me to run a
script called "maemo-sdk-install_4.0.sh", which is different to
the maemo-scratchbox-install_4.0.sh I've already got.
For those keeping score, I have therefore fucked up the
installation once again. I now need to uninstall everything and
start from scratch.
aeon:~# wget http://repository.maemo.org/stable/chinook/maemo-scratchbox-install_4.0.sh
aeon:~# sh maemo-scratchbox-install_4.0.sh -u mexon
mexon@aeon:~$ wget http://repository.maemo.org/stable/chinook/maemo-sdk-install_4.0.sh
mexon@aeon:~$ sh maemo-sdk-install_4.0.sh
For reference:
Installation about to begin with following settings:
Installed component: maemo-sdk-dev
Install free components only: no
X86 target name: CHINOOK_X86
Armel target name: CHINOOK_ARMEL
Overwrite existing targets: no
Proxy server:
Alternative sources.list:
Ah, this is looking much much better!
Another step is installing Xephyr:
aeon:~# aptitude install xserver-xephyr
Dear me, this is taking up a lot of disk space. Lucky I've got
so much free. Over 6GB!
Now is a good time to remind myself what the hell I'm trying to
accomplish. It's not installing courier: I think I'm leaning
towards using claws mail as my client, which can work directly
with maildir. Instead, I think I'm cutting straight to the
chase and going for clisp. This should at least have relatively
few dependencies. Although now I look at it, it depends on a
whole pile of X stuff. Exactly what the hell for, I have no
idea.
OK, so that seems to have worked:
Installation was successful!
----------------------------
IMPORTANT! Please read this.
You now have the maemo 4.0 chinook installed on your computer.
You can now start your maemo SDK session with /scratchbox/login and
then select your target with 'sb-conf select CHINOOK_ARMEL' for the
armel target or 'sb-conf select CHINOOK_X86' for the i386 target.
If you have any problems with targets' package databases, you can try
running 'fakeroot apt-get -f install' on your scratchbox target.
This command will try to fix any problems with the package database.
Nokia EUSA binaries
-------------------
The package maemo-explicit is a metapackage of Nokia EUSA licensed
binaries which can be installed to scratchbox targets. It is highly
recommended to install this package on both targets to ensure a fully
working system.
If you want to install these, login to scratchbox (see commands above)
and run the command 'fakeroot apt-get install maemo-explicit' for both
armel (CHINOOK_ARMEL) and i386 (CHINOOK_X86) targets.
Happy hacking!
mexon@aeon:~$
So, onwards and upwards:
mexon@aeon:~$ /scratchbox/login
Welcome to Scratchbox, the cross-compilation toolkit!
Use 'sb-menu' to change your compilation target.
See /scratchbox/doc/ for documentation.
[sbox-CHINOOK_ARMEL: ~] > sb-conf select CHINOOK_X86
Shell restarting...
[sbox-CHINOOK_X86: ~] > apt-get install iputils-ping
Still can't ping though. But wget works, so I do have internet
access. That's nice.
[sbox-CHINOOK_X86: ~/clisp] > wget http://ftp.de.debian.org/debian/pool/main/c/clisp/clisp_2.41.orig.tar.gz
[sbox-CHINOOK_X86: ~/clisp] > wget http://ftp.de.debian.org/debian/pool/main/c/clisp/clisp_2.41-1.dsc
[sbox-CHINOOK_X86: ~/clisp] > wget http://ftp.de.debian.org/debian/pool/main/c/clisp/clisp_2.41-1.diff.gz
[sbox-CHINOOK_X86: ~/clisp] > tar xzvf clisp_2.41.orig.tar.gz
[sbox-CHINOOK_X86: ~/clisp] > gunzip clisp_2.41-1.diff.gz
[sbox-CHINOOK_X86: ~/clisp] > patch -p0 < clisp_2.41-1.diff
[sbox-CHINOOK_X86: ~/clisp] > cd clisp-2.41.orig
[sbox-CHINOOK_X86: ~/clisp/clisp-2.41.orig] > dpkg-buildpackage -rfakeroot -uc -b
dpkg-buildpackage: source package is clisp
dpkg-buildpackage: source version is 1:2.41-1
dpkg-buildpackage: source changed by Peter Van Eynde
dpkg-buildpackage: host architecture i386
dpkg-buildpackage: source version without epoch 2.41-1
: Using Scratchbox tools to satisfy builddeps
: Dependency provided by Scratchbox: bison
dpkg-checkbuilddeps: Unmet build dependencies: groff xutils libsigsegv-dev (>= 2.4-1) libreadline5-dev dh-lisp (>= 0.3) gcc-4.1
dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: (Use -d flag to override.)
You know what, that'll do for today. I'll find those packages
and install them, and then try again.
But just for the hell of it, I'm running Xephyr. Fun!
Right, so groff is easy. Oh, and by the way, I installed gcc
and make on the n810 just now. Pity I have so little disk space
there. xutils isn't available. And neither are any of the
others. So this will take quite a lot of work. Do you suppose
I use sarge or etch?
I've been completely unable to figure out the answer to that
question, so I'm going with etch until I reach an
incompatibility.
xutils depends on libfs-dev. Apparently x11proto-fonts-dev
replaces it. So I edited the control file to say that. I'm not
highly confident that this will work. No, configure failed. By
the way, x11proto-fonts-dev only shows up in etch. So I'm
building libfs.
That built xutils, but to install it I need xfonts-utils and
xutils-dev. I'm a little nervous now. What if Nokia has
extensively fucked around with X somehow? Hmm, I should have
been building xutils-dev shouldn't I? Actually, it seems I need
both. Anyway, now xfonts-utils. Which needs xfonts-encodings.
Hmm. Before I can build xfonts-encodings, I need to have
installed xfonts-utils. This is a bit circular, isn't it? I'm
going to try removing xfonts-encodings as a dependency of
xfonts-utils, then build xfonts-utils and install. Then I'm
going to try building and installing xfonts-encodings. Finally,
I'll try putting back the dependency in xfonts-utils, rebuild
and install. Wow, that actually worked. Fuck I'm good.
That allows me to install xutils, and so that's one dependency
down. Next, libsigsegv-dev. Oh, yikes. Dependency on gcc-4.1.
And my clisp depends on version 2.4-1, which is above the sarge
version, so downgrading to sarge isn't an option unless I do
that with clisp as well. Which I could do. The sarge backport
version might work. Seems to.
So next. libreadline5-dev. I'm going to go back to etch from
now on, just because. And libreadline needs lots of stuff:
lib64ncurses5-dev texinfo libc6-dev-amd64 lib64gcc1. Well,
texinfo at least is installable. Just what the hell is there a
dependency on libc6-dev-amd64 for anyway? Maybe I should tackle
that first. Oh, gee whiz, dependency on gcc-4.1, what a
surprise. Fuck it, let's have a go. No, no, look at those
dependencies, this'll take an age. I should do libc6-dev-amd64
under gcc 3. In fact, I should do libreadline5-dev under sarge.
Oddly enough, that's now just going, no dependencies needed.
Yay.
So just dh-lisp to go. Which is only available in
sarge-backports, so I guess that's the one I'll be using. At
least it's fairly painless - not even a patch. But I still
expect that this isn't it - clisp may build, but there will be
other dependencies before I can install.
Yes, I need common-lisp-controller. From backports, again. And
that depends on realpath and cl-asdf. Realpath is easy.
cl-asdf will be another backport.
Yikes, cl-asdf needs tetex-bin to be installed. And that
depends on a whole gigantic pile of stuff. Plus,
common-lisp-controller is stuck in a bad state where it can't be
configured or uninstalled. Ah, OK that problem was solved with
"dpkg --remove common-lisp-controller". Hmm, no it wasn't. Ah,
wait, yes it was, but I need to "dpkg --remove clisp" as well.
And then I can install tetex-bin just with apt-get install.
Yay. In fact, thank Christ. That would have really
screwed me.
I still need cvs2cl though. And that needs perl-doc. But
that's been replaced by perl. So maybe I get the sarge version
of cvs2cl. No, that doesn't help. So maybe I just hack the
dependencies. I change the control file to make the dependency
perl not perl-doc. Oh, and cvs2cl depends on cvs, which isn't
available through apt-get. Sigh. Well, I can try.
So, cvs has two build dependencies, libpam0g-dev and texi2html.
Lord knows what install dependencies there will be.
The former is a sarge backport. Pam is a scary-ass big package.
I expect build dependency problems. Yep: cracklib2-dev (>=
2.7-9) libdb4.3-dev libcap-dev linuxdoc-tools
linuxdoc-tools-latex tetex-extra opensp. tetex-extra is OK with
apt-get. So is linuxdoc-tools. Apparently linuxdoc-tools
replaces linuxdoc-tools-latex.
But cracklib doesn't want to install at all. Man, do I really
need cracklib? Ah, I guess I can try an older version. Oh,
wait. Weirdly, that patch seems to rename the directory. That
probably explains why I couldn't build it. Ah, I get it. The
tarball extracts to cracklib,2.7. I have to rename that to
cracklib2_2.7 before I can patch it. OK. But nevertheless, the
etch version doesn't work. The sarge version seems to work
though.
I think I've changed my mind. I want the sarge version of cvs.
I think that's going to be easier. Same dependencies. By the
way, texi2html comes from apt-get. But I'm switching to the
sarge libpam0g-dev. And yes, this was a good idea, because now
I'm installing libdb3-dev.
Which depends on TCL! Holy fuck! I'm going to try just
removing cvs2cl from the dependencies of cl-asdf. I can't even
find any references to the script in the patched tarball. Seems
to install. And so does common-lisp-controller. And so does
clisp! Hooray!
So now what? I have to do all of that again, but in ARMEL.
Let's try and make two lists. Things to install with apt-get:
- groff (build clisp)
- texinfo (build libreadline5-dev)
- tetex-bin (build cl-asdf)
And things I have to build:
- clisp (duh!)
- xutils-dev (maybe not?) and xutils (build clisp)
- libfs-dev (build xutils-dev)
- xfonts-utils (install xutils)
- xfonts-encodings (build xfonts-utils, note circular dependency)
- libsigsegv-dev (build clisp)
- libreadline5-dev (build clisp)
- dh-lisp (build clisp)
- common-lisp-controller (install clisp)
- realpath (install common-lisp-controller)
- cl-asdf (install common-lisp-controller)
Changing my target is done with sb-menu. Although I had to
killall first. Now I have all my previous stuff here, and I
don't know exactly how this is going to work. The tutorial
seems reassuring, but I certainly do have to apt-get install the
things which need to be installed, like groff.
This time I'm going to do everything as sarge, and update the
dependencies above accordingly. I guess. Well, it's already
different: I need xlibs-dev instead of xutils. And wow, it's a
big 'un. 60MB of source! No wonder - it's the whole fucking
thing. And that needs all of m4 dbs bzip2 bsdmainutils bison.
dbs and bsdmainutils aren't apt-get installable. So I'm going
to use the backported clisp after all.
Aw man, xutils-dev from the backport drags down the whole of
xorg! I'll use the etch version instead.
And after all that, it doesn't compile on ARM anyway. Boo!
In fact, this should be no surprise. Debian doesn't list arm as
a valid platform for that package. The etch version, 1:2.41-1,
does however. So I'm going to just have to buckle down and
figure out how to get that working.
I think the dependency on gcc-4.1 is a crock. It's just the
etch policy. I'm going to try changing it to just gcc and see
what happens. I still need a better version of libsigsegv-dev.
Nope, after all that I still get the same error. So this is
completely screwed. Damn.
Oh, fuck, here's
someone trying to do exactly what I'm doing! What are the
chances of there being two?
OK, before I ping him, one last possibility. Try going
backwards, to sarge. Note that this gives me the xorg problem.
Hmm, you know what, I must have all the X development
libraries installed somewhere. Probably in all that
x11proto-*-dev stuff. So I could try just removing the
dependency and see what happens. Configure will tell me what's
missing, if anything. See, it seems happy. Oh, wait, spoke too
soon, there are other configure bits. There may be an X
component that fails somewhere.
Well, that was unexpected:
make[2]: Leaving directory `/home/mexon/armel/clisp/clisp-2.33.2/debian/build/libcharset'
gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wno-sign-compare -O2 -DUNICODE -DDYNAMIC_FFI -I. -c spvw.c
In file included from /usr/include/sys/procfs.h:34,
from /usr/include/sys/ucontext.h:26,
from /usr/include/signal.h:351,
from unix.d:206,
from lispbibl.d:1710,
from spvw.d:24:
/usr/include/sys/user.h:31: error: syntax error before "void"
/usr/include/sys/user.h:32: error: syntax error before ':' token
/usr/include/sys/user.h:33: error: syntax error before ':' token
/usr/include/sys/user.h:34: error: syntax error before ':' token
/usr/include/sys/user.h:35: error: syntax error before ':' token
/usr/include/sys/user.h:36: error: syntax error before ':' token
/usr/include/sys/user.h:38: error: syntax error before ':' token
/usr/include/sys/user.h:39: error: syntax error before ':' token
/usr/include/sys/user.h:42: error: syntax error before '}' token
/usr/include/sys/user.h:68: error: field `u_fp' has incomplete type
In file included from spvw.d:24:
lispbibl.d:7431: warning: volatile register variables don't work as you might wish
make[1]: *** [spvw.o] Error 1
make[1]: Leaving directory `/home/mexon/armel/clisp/clisp-2.33.2/debian/build'
make: *** [build-stamp] Error 2
Weird, I've never seen syntax like this before:
struct user_fpregs
{
struct fp_reg
{
unsigned int sign1:1;
unsigned int unused:15;
unsigned int sign2:1;
unsigned int exponent:14;
unsigned int j:1;
unsigned int mantissa1:31;
unsigned int mantissa0:32;
} fpregs[8];
unsigned int fpsr:32;
unsigned int fpcr:32;
unsigned char ftype[8];
unsigned int init_flag;
};
Someone
else has the same problem, also with ARM.
I only just remembered why I started this in the first place. I
need to write a perl script to resize photos to something
suitable for the blog. That's going to need a few perl
libraries. That's all. Shouldn't be a drama.
Also, there is one more thing I can try with clisp: try the
latest tarball from the website. Who knows, it might be
worthwhile. I've been playing with 2.41 and 2.44 is available.
Also note the existence of this
intriguing link. It seems to imply that there's nothing
about ARMEL per se that prevents clisp working.
I tried the latest tarball of clisp, and I'm doing it the normal
way, no Debian. Interestingly, it doesn't want to use FFI. I
keep telling it to, with things like this copied from the
debian/rules file:
[sbox-CHINOOK_ARMEL: ~/armel/clisp/clisp-2.44] > sh configure --prefix=/home/mexon/armel/clisp/clisp-2.44/install --with-dynamic-ffi --with-dynamic-modules --with-module=bindings/glibc --with-module=clx/new-clx
...
Configure findings:
FFI: no (user requested: default)
readline: yes (user requested: default)
libsigsegv: yes
./makemake --with-dynamic-modules --prefix=/home/mexon/armel/clisp/clisp-2.44/install --with-dynamic-ffi --with-module=bindings/glibc --with-module=clx/new-clx > Makefile
make: `config.lisp' is up to date.
To continue building CLISP, the following commands are recommended
(cf. unix/INSTALL step 4 ff):
cd src
vi config.lisp
make
make check
Also important is that I had to set "ulimit -s 16384". I wonder
if the Debian version is doing that? Worth another shot,
I'd say. No, that doesn't help.
But I did confirm that the regular Debian package also gets a
message saying that there's no FFI. So let's just carry on and
see what happens.
Oh, this
bug suggests that it might just be broken.
Boo. Still
true in 2007. That kinda fucks me up, actually.
Oh, this
is new. Someone trying to compile it for the N800, with
success. But they get no FFI.
Also someone
doing it for the Zaurus. And by the way, I just got the same
stuff about redefining a built-in register in ariarm.s when
trying to compile 2.44. So I'm in all sorts of difficulties
now.
Oh! Look at this:
So, for future reference for anyone else trying to get it
going on small ARM linux platforms:
CFLAGS="-DNO_GENERATIONAL_GC" and install GNU sed is all it
takes to get it to work on the Nokia N800. There are no
particular configure options needed to make it work.
I already have GNU sed installed. And also:
In fact, despite vacall-arm being broken, it managed to compile
at least enough of the FFI bits and pieces for readline to work
(the module seems to depend on the existence of it - certainly
it didn't compile when set up with
configure --without-dynamic-ffi. The defpackage in readline.lisp
says it uses (:use "CL" "EXT" "FFI"))
So there's hope yet. I do, in fact, use floats theoretically.
But practically speaking, I don't need them.
I need to get the FUSE module
working. Here
are instructions. It really appears to be just a question of
compiling the kernel with the appropriate thing as a module, and
then copying the .ko to the device.
Well, I installed the kernel module OK. Wow. That's my first
self-compiled thing installed on the N810. Go me!
So uh, what about emacs? How come it's 30 odd MB when Debian's
version is about 12? I might as well have a go compiling it
myself. Dependencies are: mailx liblockfile-dev libungif4-dev
xaw3dg-dev sharutils imagemagick
mailx needs liblockfile-dev. Presumably at some point, I will
have compiled all of Debian, and this will get easier. I'm
actually finding it necessary to rename "eaccess" to "eaccess2"
so that I can get this thing to compile. In lockfile.c and
dotlockfile.c. Using sed -i 's/eaccess/eaccess2/g'.
To install mailx, I need mail-transport-agent. What's that
gonna be, maybe postfix? No, scary dependencies. Sendmail
seems OK. Xmail seems smaller though. Seems happy enough. But
conflicts with lsb! Wah! OK, sendmail. For which I need
libdb4.2-dev libldap2-dev libwrap0-dev libsasl2-dev. Well,
libdb4.2 is installed, and I can get the source with apt-get
source.
Incidentally, the emacs from the internet is installing over on
the machine. But it doesn't have enough space, so lord knows
what will happen. Wow, it failed completely silently, how about
that. Luckily it uninstalled OK, no bones broken. I'd expected
it to fail for lack of dependencies, but apparently not.
I had all sorts of fun with my emacs directory. It was mounted,
but it didn't like the tar archive, because it evaporates to
zero when you remove the last file, and apparently that's an
invalid archive. Or wait, maybe I deleted that. Whatever, the
result was an invisible directory that couldn't be seen or
deleted. But it fusermount -u'ed OK. Then I got it mounted,
but it's not even writable by root, which is weird. So I made
user chmod to to 777. Which doesn't help. I need an option -
but fusermount doesn't have a useful manpage.
Hmm, libdb4.2-dev conflicts with libdb1-dev. But that's part of
maemo-core-dev. Am I really going to try for exim? That
depends on libdb3-dev. Hmm.
Let's try convincing emacs that it really doesn't need mailx in
order to build.
The etch version of imagemagick doesn't patch. Neither does the
sarge version. WTF?
I'm back to the downloaded version. According to this page,
the solution is to create /etc/fuse.conf with the word
"user_allow_other", and to use "archivemount -o allow_other
/media/mmc2/emacs.tar emacs".
OK, that got a little further. But it seems that the
documentation deleter doesn't understand about --instdir. Hmm,
well it's not docpurge, since that just removes everything in
certain target directories.
Oh, that is weird. I can't unlink changelog.gz.dpkg-new. It
says "Numerical result out of range". Oddly enough, it has
permissions of zero. That could explain it, I guess. Oh, the
tar file is corrupt. That's no good. Same problem with zip.
Damn. That sucks.
So my best hope is to install emacs normally, then move files
into the tar. But I have a problem. I no longer have enough
space to install emacs. Even after removing gcc and make and
dpkg-dev and all kinds of things. I think I need aptitude to
help me clean out the cruft.
In an attempt to figure out if there was one over-arching
dependency, I removed osso-af. I should put it back as soon as
possible. That isn't now, however, because of the broken emacs
install. Oh, in fact I can install it, which fails silently,
and then remove it again that way.
I can probably go over the list of installed files from dpkg -l
and run "dpkg --dry-run --remove $i" to see if it would work or
not. That would tell me if anything is uninstallable, that I
don't really need.
Oh, fuck me! Emacs actually installed! Well, isn't that
exciting?
It's only for pride, but I'll have a go at encfs. Needs
librlog-dev librlog1c2a libssl-dev. Oh, wait, libssl-dev is
there but the etch encfs wants a later version. So back to
sarge. Now it's just librlog-dev. That requires oxygen, but
it's apt-get installable.
Given that I'm going to need courier-mta anyway, I should try to
port courier first. If that works, I can have another go at
Emacs. Courier's dependencies look good in any case - no libdb!
Build dependencies for courier:
dpkg-checkbuilddeps: Unmet build dependencies: libmysqlclient-dev | libmysqlclient15-dev libpam0g-dev libgdbm-dev | libgdbmg1-dev libperl-dev libpcre3-dev libldap-dev libsasl2-dev | libsasl-dev expect gs | gs-aladdin mgetty-fax netpbm libfam-dev libpq-dev | postgresql-dev courier-authlib-dev
Holy crap. OK then. Dependencies of mysql: libwrap0-dev (>=
7.6-8.3) psmisc chrpath tetex-extra gs. libwrap0-dev was easy.
psmisc also seems to be going. As does chrpath. tetex-extra
comes from apt-get - didn't I install that before? No, that was
tetex-bin. gs is now gs-gpl. Still can't apt-get it though.
To build, I need automaken libglut-dev libpaper-dev. automaken
is actually provided by any automake, so I've gone for the
latest, automake1.9. That'll be libglut3-dev I want. Glut is
huge. Luckily, it seems to be building. libpaper-dev is
building. In the meantime, I can't install glut stuff until
I've installed freeglut3.
Dependencies for freeglut3: xlibmesa-gl-dev | mesag-dev |
libgl-dev libglu1-xorg-dev | xlibmesa-glu-dev | libglu-dev.
libgl-dev doesn't seem to be available. I'm going for
xlibmesa-gl-dev. Um, that would be xorg! Ah, I see, it's just
a virtual package, the real one is libgl1-mesa-dev. Which is
probably what the libgl-dev thing was trying to redirect me to
in the first place. And mesa doesn't patch. Let's try the
sarge version.
Holy crap, why is this 50MB big? Because it's the whole of
xfree86, that's why. OK, one try. Inside the orig tarball is
another tarball. Surprisingly, fairly mild dependency hell:
libpam0g-dev | libpam-dev lynx. Hmm, libpam-dev depends on
libpam0g-dev. Funny, it claims that I've done this before, but
I can't find it. Ah, OK, I was doing it under x86.
Dependencies of pam: cracklib2-dev (>= 2.7-9) libdb3-dev
libcap-dev linuxdoc-tools linuxdoc-tools-latex opensp. And
libdb3 is where things start to go pear-shaped. Yes, libdb3-dev
depends on tcl, of all things. For example, tcl8.4. I have to
"mv tcl8.4.12 tcl8.4-8.4.12.orig". Incredibly, tcl is going.
cracklib2-dev needs cdbs. Which is "common build system for
Debian packages". Hah! As if. Note that this is the first
time I've encountered it. Oh, and I can apt-get it. Note that
cracklib is the evil one where I have to mv cracklib,2.7
cracklib2-2.7.
Bugger. libdb3-dev depends specifically on tcl8.3. "mv
tcl8.3.5 tcl8.3-8.3.5.orig".
Cracklib isn't compiling.
dpkg-buildpackage: source package is cracklib2
dpkg-buildpackage: source version is 2.7-19
dpkg-buildpackage: source changed by Martin Pitt
dpkg-buildpackage: host architecture armel
dpkg-buildpackage: source version without epoch 2.7-19
: Using Scratchbox tools to satisfy builddeps
fakeroot debian/rules clean
test -x debian/rules
make: *** [testdir] Error 1
Maybe sarge. No, ultimately the same version. Oh, but it works
better. Good.
libcap-dev seems to be OK. linuxdoc-tools is apt-gettable. And
something called "sp" is coming along with them, which is
presumably related to "opensp". linuxdoc-tools appears to
replace linuxdoc-tools-latex.
Yes, and here's the problem: libdb3-dev conflicts with
libdb1-dev. Can I remove it? Yes, I can. Groovy.
pam really seems to want linuxdoc-tools-latex. Maybe I can get
away with editing the control file. But I'd better get opensp.
opensp depends on xmlto gs-common openjade1.3 | openjade jadetex
docbook-dsssl. docbook-dsssl is apt-gettable. It brought
openjade with it. And jadetex is apt-gettable. And xmlto as
well. Only gs-common is missing. gs-common seems to be just
little Debian glue code. But I need gs in order to install
gs-common. Have I reached the dreaded circular dependency?
gs-gpl build-> libglut-dev install-> freeglut3 build->
xlibmesa-gl-dev build-> mesa build-> libpam-dev build-> opensp
build-> gs-common install-> gs-gpl. I'm going to try switching
to gs-afpl.
gs-afpl depends on libjasper-1.701-dev x-dev. x-dev is just a
dummy package that depends on x11proto-core-dev, which is
already installed. Dummy package or not, I still have to "mv
xproto-7.0.7 x11proto-core-7.0.7".
Note that gs-afpl is also evil: "mv ghostscript-8.53
gs-afpl-8.53".
libjasper depends on libglut3-dev. Ouch. So I have one last
chance. gs-esp. I don't hold out much hope though, too similar
to the others. OK, it depends on libcupsys2-dev and
libcupsimage2-dev.
So let's try cups. "mv cups-1.2.7 cupsys-1.2.7.orig". Nope,
depends on pam. Bugger.
I'm going to try manually removing the dependency on gs-common
of opensp, and trying to cripple whatever it tries to do that it
seems to feel needs it. It's got a configure script. Is it
going to be a fascist?
configure: error: could not find pdf2ps; set PDF2PS or consider --disable-doc-build
make: *** [config-stamp] Error 1
I can do that! Change --enable-full-doc-build in rules to
--disable-doc-build. Failing that, setting PDF2PS to cat would
work fine. That may yet be necessary, since it will probably
try to copy the generated documentation into the .deb.
This is almost like playing a video game. A very stupid and
dull computer game. But then, aren't they all?
opensp is taking ages and ages to build. Get used to it Mat.
Still got xfree86 to go.
And it failed. I'm removing dh_installdocs from the rules file.
And also dh_installman.
2010-04-06
Update from Nito (working
on the QVD virtualisation
platform):
I got workaround this by creating a stub /usr/bin/man shell
script that basically returns 0 (the error is in the manpage)
OK, opensp is installed, minus documentation. Time to work back
through the chain. To libpam-dev, which needs
linuxdoc-tools-latex. So forwards again. Now
linuxdoc-tools-latex is going. And now, finally, pam is going.
And compilation fails. Bugger. I can try the etch version. Oh
great, depends on libdb4.3-dev libselinux1-dev.
"mv db-4.3.29 db4.3-4.3.29.orig". Oh man, that ain't good:
java-gcj-compat-dev. No way, I can't do that.
pam_handlers.c: In function `_pam_parse_conf_file':
pam_handlers.c:267: error: label at end of compound statement
I fixed it by adding dummy (extremely dumb) statements around
the offending statement. And that seems to have improved
matters considerably. Something
to do with new compilers being more paranoid.
An awful lot of tex documentation is being made during this
session. I swear, this is taking years to do. I don't need all
this sodding Tex documentation, you bastard! You're like 10
levels of dependency down from where I want to be.
Well it finally went, and libpam0g-dev is installed. Now, I
still have lynx to do. "mv lynx2-8-5 lynx-2.8.5.orig". I need
libncursesw5-dev libgnutls-dev. The former is apt-gettable. I
foresee ugliness with the encryption stuff though. "mv
gnutls-1.4.4 gnutls13-1.4.4". Yeah, libgcrypt11-dev (>= 1.2.2)
libopencdk8-dev (>= 0.5.5-8) liblzo-dev gtk-doc-tools texinfo
(>= 4.8) libtasn1-3-dev (>= 0.3.4-1)
Let's jump back up to libmysqlclient-dev. The only unmet
dependency is gs, and surely I got that, didn't I? No, I
haven't yet got gs. But wait, the same trick will probably work
for mysql, if it has a documentation target. So I just remove
the target, build, and see what breaks. Of course, it'll break
right at the end, which is a pain.
Just for the hell of it, I'm returning to some of those lynx
dependencies. texinfo is weird: it's installed with the sarge
version, but in order to compile the sarge version of lynx you
need the etch version of texinfo! Texinfo seems to be compiling
though. But it won't install, because it conflicts with the
version of tetex-bin that's installed. You know, I don't
believe that lynx really requires such a recent version of
texinfo. Oh, not lynx, libgnutls-dev, that's what depends on
texinfo. Hmm, actually I should be going for the sarge
libgnutls-dev, since that's probably got lighter dependencies.
Hmm, not really. At least liblzo-dev is apt-gettable.
This really has to be the last one for tonight. "mv
opencdk-0.5.5 opencdk8-0.5.5". Depends on libgcrypt11-dev.
mysql failed to compile. Mind you, that was after the
documentation had already failed to compile, so maybe I
shouldn't be surprised.
Fuck it, one more. libgcrypt11-dev depends on docbook-utils
docbook-to-man jade libgpg-error-dev docbook-utils
docbook-to-man jade, but all except libgpg-error-dev are
apt-gettable.
Oh OK, one last one. This is really addictive. It's
the way you can make one tiny little step forward at every
stage, forgetting how far off in the distance your eventual goal
really is. But I can say that libgpg-error-dev is compiling
straight away without any other dependencies. It's quite small.
And for some reason libgcrypt fails straight away. That sure is
weird.
[sbox-CHINOOK_ARMEL: ~/courier/libgcrypt11-dev/libgcrypt11-1.2.0] > dpkg-buildpackage -rfakeroot -uc -b
dpkg-buildpackage: source package is libgcrypt11
dpkg-buildpackage: source version is 1.2.0-11.1
dpkg-buildpackage: source changed by Bas Zoetekouw
dpkg-buildpackage: host architecture armel
dpkg-buildpackage: source version without epoch 1.2.0-11.1
: Using Scratchbox tools to satisfy builddeps
fakeroot debian/rules clean
/usr/share/cdbs/1/rules/buildcore.mk:68: Parsing libgcrypt-1.2.0.tar.gz...
test -x debian/rules
make: *** [testdir] Error 1
Fix it with "chmod a+x debian/rules".
Refuses to compile because it doesn't have dvips. apt-get
claims it's handled by tetex-bin. On Aeon, tetex-bin does
indeed install dvips. But it's version 2.0.2, and Aeon's using
3.0-30. I could try making tetex work, I guess.
"mv tetex-src-3.0 tetex-bin-3.0". Requires libt1-dev (>=
5.0.0-3) eperl debiandoc-sgml libpoppler-dev libgd2-xpm-dev.
debiandoc-sgml is apt-gettable. No, I don't like the idea of
diving into tetex and then eperl. That's just too much.
Ah! Inspiration! How about apt-get source tetex-bin?
Actually, not inspiration, desperation. Hmm, that requires
libwww-dev and libwww0. I can't even build here. That's not
very good.
libwww requires mpack (>= 1.5-7) bzip2 (>= 1.0.2-1). bzip2 is
apt-gettable, mpack not. mpack went easy.
By the way, it looks like setting up a Debian repository isn't
that
hard. A
debian administration
article. A
package.
libwww0 built. A lot of work for only four debs. So back to
tetex. But it doesn't like my libs!
OK, I solved that somehow. Sorry, can't remember how. I built
tetex-bin, but it wouldn't install:
Setting up tetex-bin (2.0.2+maemo-30osso3) ...
Merging information from /etc/texmf/texmf.d/ into /etc/texmf/texmf.cnf ... done
Regenerating /var/lib/texmf/web2c/fmtutil.cnf ... done
Regenerating /var/lib/texmf/web2c/updmap.cfg ... done
mv: cannot stat `/targets/CHINOOK_ARMEL/etc/texmf/language.dat': No such file or directory
dpkg: error processing tetex-bin (--install):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
tetex-bin
So then I just did "apt-get install tetex-bin", intending to
replace my broken version with the official version. And it
seems to be working. Weird. And there's no dvips in there
anyway. Ah, the debian/rules file has --without-odvipsk in
there. Whereas the sarge version doesn't. So two options.
Either continue trying to build sarge... no, not for the moment,
depends xlibs-dev libt1-dev. Or hack the rules file in the
maemo version and see what happens.
This happens:
make[3]: Entering directory `/home/mexon/courier/tetex-bin/tetex-bin-2.0.2+maemo/texk/makeindexk'
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -g -O2 -c genind.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -g -O2 -c mkind.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -g -O2 -c qsort.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -g -O2 -c scanid.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -g -O2 -c scanst.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./.. -g -O2 -c sortid.c
./../klibtool link gcc -o makeindex genind.o mkind.o qsort.o scanid.o scanst.o sortid.o ../kpathsea/libkpathsea.la
gcc -o makeindex.exe genind.o mkind.o qsort.o scanid.o scanst.o sortid.o -L../kpathsea/SHARED -lkpathsea
make[3]: Leaving directory `/home/mexon/courier/tetex-bin/tetex-bin-2.0.2+maemo/texk/makeindexk'
make[3]: Entering directory `/home/mexon/courier/tetex-bin/tetex-bin-2.0.2+maemo/texk/odvipsk'
make[3]: *** No rule to make target `all'. Stop.
make[3]: Leaving directory `/home/mexon/courier/tetex-bin/tetex-bin-2.0.2+maemo/texk/odvipsk'
make[2]: *** [all] Error 1
make[2]: Leaving directory `/home/mexon/courier/tetex-bin/tetex-bin-2.0.2+maemo/texk'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/mexon/courier/tetex-bin/tetex-bin-2.0.2+maemo'
make: *** [build-stamp] Error 2
Let's have a go at libt1-dev. Even though I'm ignoring the
libx-dev thing, which is silly.
Interesting stuff going on in the diff between the rules files
in the maemo and sarge versions of tetex-bin. There's
a --with-system-t1lib flag that's been taken out. I can put it
back in now. The main thing is that they've disabled xdvi and
oxdvi, which is fair enough and I want to keep.
No, even after putting back in the --with-system-t1lib flag, it
doesn't help. No real surprise there.
I tried removing the lynx dependency for xfree86. There's no
vars.armel file, so I'm trying copying the one from vars.arm.
They're only small. Now it fails like this:
/bin/bash -e /usr/share/dbs/internal/lib "SOURCE_DIR=\"build-tree\"" "STAMP_DIR=\"stampdir\"" "VARS_FILE=\"stampdir/vars.sh\"" "STRIP_LEVEL=0" "TAR_DIR=\"xc\"" patch_apply
Applying patch debian/patches/000_post430.diff failed!
Why does freeglut depend on mesa? That's a 3D library. Let's
try removing the build dependency, see what happens. Well, it
really depends on GL. Actually, that's the whole point of GLUT.
Maybe I haven't tried installing x.org yet? Well, when I try to
find it, I end up at an etch package which is mesa but not
xfree86. And I don't seem to have tried that yet. So let's try
the etch mesa! "mv Mesa-6.5.1/ mesa-6.5.1". Depends on
lesstif2-dev grep-dctrl build-essential (>= 11) libdrm-dev (>=
2.0.2) libdirectfb-dev libxxf86vm-dev x11proto-gl-dev (>=
1.4.8). Basically lots of etch versions of things that are
already installed. build-essential depends on gcc 4, and I only
have gcc 3. So do I try to install a new gcc? I expect bad
dependency problems. Indeed: autogen dejagnu (>= 1.4.3)
expect-tcl8.3 gperf (>= 3.0.1) bison (>= 1:2.3) libmpfr-dev
sharutils realpath (>= 1.9.12) make (>= 3.81) graphviz (>= 2.2)
gsfonts-x11. That's just not gonna happen.
Maybe I could have a go at dovecot? No harder than all the
other rubbish I'm trying to compile. No, because the reason for
all of this was mysql, and dependencies of dovecot include
libldap2-dev postgresql-dev libmysqlclient12-dev libsasl2-dev |
libsasl-dev
I did find an alleged repository for mysql, but it doesn't seem
to exist any more. Damn.
The compilation failure in mysql is due to "YACC =" being
nothing. That leaves AM_YFLAGS as the only thing on the command
line, which is "-d --debug --verbose". But bison exists, so
let's try hacking it manually. Irritatingly, it can't unapply
its patches, which means every time build fails I have to
restart from scratch.
Maybe a different version of mysql. The sarge version depends
on libreadline4-dev, but libreadline4 claims to replace it. And
certainly it doesn't include the include files. So let's try
apt-get source and see what happens. Oh, I see,
libreadline5-dev conflicts. So I just remove it.
While that's going on, dependencies for postgres: libperl-dev
tk8.4-dev libkrb5-dev python-dev. I built tk8.4 earlier. None
of the others are available. No, I built tcl8.4, not tk8.4.
"mv tk8.4.12 tk8.4-8.4.12.orig". That's building.
For python, I should be able to apt-get source. It's compiling.
Incidentally, courier itself wants gs. To review. gs depends
on glut. glut depends on mesa. mesa is provided by either
xfree86 or the separate mesa package. xfree86 is failing
because of patches. I'll probably have to tackle that.
MySQL seemed to build, but python didn't:
running build_scripts
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
running install_lib
sem_post: Function not implemented
sem_post: Function not implemented
creating //home/mexon/courier/python-dev/python2.4-2.4.2+maemo1/debian/python2.4/usr/lib/python2.4/lib-dynload
sem_post: Function not implemented
sem_post: Function not implemented
copying build/lib.linux-armv5tel-2.4/struct.so -> //home/mexon/courier/python-dev/python2.4-2.4.2+maemo1/debian/python2.4/usr/lib/python2.4/lib-dynload
qemu: uncaught target signal 11 (Segmentation fault) - exiting
make[1]: *** [sharedinstall] Error 245
make[1]: Leaving directory `/home/mexon/courier/python-dev/python2.4-2.4.2+maemo1/build'
make: *** [stamp-install] Error 2
Perl depends on libgdbm-dev.
I should apt-get source x11-common. For various reasons. And
probably xserver-xomap.
This is what happened to python this time:
copying build/lib.linux-armv5tel-2.4/struct.so -> //home/mexon/courier/python-dev/python2.4-2.4.2+maemo1/debian/python2.4/usr/lib/python2.4/lib-dynload
qemu: uncaught target signal 4 (Illegal instruction) - exiting
make[1]: *** [sharedinstall] Error 252
make[1]: Leaving directory `/home/mexon/courier/python-dev/python2.4-2.4.2+maemo1/build'
make: *** [stamp-install] Error 2
On the plus side, perl's done. I'm trying the apt-get
sourceversion of xserver-xomap. I need x11proto-core-dev. No
wait, weird. I need a version bigger than the one that's
actually installed. Luckily, apt-get source gets exactly that.
gs-esp depends on cups, but cups might now be a possibility.
Outstanding dependencies are libslp-dev libgnutls-dev
libldap2-dev sharutils, all of which could go. sharutils is
apt-gettable.
libslp-dev conflicts with libssl-dev, but it's easy to remove
that. And it's going.
Which is great, but cups also depends on libgnutls-dev, that
depends on libgcrypt11-dev, and that depends on dvips.
I could have another go at the etch tetex. I abandoned that
last time because it depended on eperl, but I realise that eperl
is a light wrapper around perl. Also, I built perl anyway.
eperl is building now. Oh, but it fails:
gcc -Wl,-E -L/usr/local/lib -L/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/CORE -o eperl eperl_main.o eperl_perl5.o eperl_parse.o eperl_pp.o eperl_sys.o eperl_http.o eperl_getopt.o eperl_debug.o eperl_config.o eperl_version.o eperl_readme.o eperl_license.o eperl_logo.o eperl_powered.o /scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/bin/../lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../arm-none-linux-gnueabi/bin/ld: /scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a(DynaLoader.o): Relocations in generic ELF (EM: 3)
/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
So sarge tetex depends on xlibs-dev, which is from xfree86.
When I left that last, I'd just removed lynx to see what
happens, and it was complaining about some patches. So I can
try removing the offending patches. No, the one that failed is
the very first one, which probably brings it back to an unusable
state. Probably something's buggy.
Wait. Now it's applying the patches. What I'm doing
differently is that I moved to the source tarball's name, not
the patch's name. So I expect this to fail, but I expect it to
fail because of lynx. That's progress.
Right, it fails fairly quickly like this:
# Generate plain text documents from (X)HTML.
lynx -dump -nolist debian/local/xterm.faq.html >debian/local/xterm.faq
/scratchbox/tools/bin/bash: line 1: lynx: command not found
make: *** [stampdir/build] Error 127
Here's my solution. Do you like it?
[sbox-CHINOOK_ARMEL: ~/courier/libgl1-mesa-dev/xfree86-4.3.0] > cat /usr/bin/lynx
#! /usr/bin/bash
echo $@
Guess what? The entire X build failed like this:
Output written on sync.dvi (18 pages, 41308 bytes).
Transcript written on sync.log.
dvips -o sync.nps sync && mv -f sync.nps sync.ps
/scratchbox/tools/bin/sh: line 1: dvips: command not found
make[6]: *** [sync.ps] Error 127
My solution?
[sbox-CHINOOK_ARMEL: ~/courier/libgl1-mesa-dev/xfree86-4.3.0] > cp /usr/bin/lynx /usr/bin/dvips
No, that's not going to work.
[sbox-CHINOOK_ARMEL: ~/courier/libgl1-mesa-dev/xfree86-4.3.0] > cat /usr/bin/dvips
#!/usr/bin/perl
use Getopt::Long;
my $output;
$result = GetOptions ("output=s" => \$output );
if ($output)
{
open(OUTPUT, "> $output");
print(OUTPUT "Generated by dummy dvips.\n");
}
Maybe sarge python? Missing dependencies: libdb4.2-dev
libgmp3-dev blt-dev (>= 2.4z) tix8.1-dev (>= 8.1.3.93)
libssl-dev emacs21. Emacs21! For fuck's sake! Let's see about
the Etch version. Yes, similarly, libreadline5-dev libdb4.4-dev
blt-dev (>= 2.4z) libssl-dev libgpmg1 emacs21.
Right, someone
else already has python-dev. So something's up. And this
is just irritating. I tried adding bora to my sources.list, but
it didn't come. Here's a whole
pile of notes. And, here,
he notices the same segfaults I'm seeing. I don't understand
his solution:
However, maemo has python2.4 and python2.4-dev so we can
force python-all python-central python-dev
Ah, wait, maybe I understand. No, wait, I don't. Maemo
doesn't have python2.4-dev, that's the whole point.
But, what I maybe do understand is that maybe I can bypass
Debian and build from source. I can cheerfully let it trash
/usr if it wants. Then I'll have the binaries in place, and I
can proceed with the rest of the build.
Except that, you know, I still don't have emacs installed. But
presumably a configure script will pick that up and throw away
whatever piece needs that.
Configure is running, and not quickly. But my question is, will
that actually install the things that Debian wants? Maybe it
really wants some weird headers or something. Well, configure
seems happy, so I guess I make. And now I'm going to bed, with
both x and python compiling away.
Both of those failed. X failed like this:
make[5]: Entering directory `/home/mexon/courier/libgl1-mesa-dev/xfree86-4.3.0/build-tree/xc-xserver-xfree86-dbg/lib/Xp'
rm -f XpAttr.o unshared/XpAttr.o
gcc -c -fsigned-char -I../.. -I../../exports/include -I/usr/X11R6/include -Dlinux -D__arm__ -D__arm32__ -U__arm -Uarm -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DMALLOC_0_RETURNS_NULL -g -O0 -fno-strict-aliasing -g XpAttr.c -o unshared/XpAttr.o
In file included from ../../exports/include/X11/extensions/Printstr.h:66,
from XpAttr.c:41:
/usr/include/X11/Xlib.h:3578: error: syntax error before "_X_SENTINEL"
/usr/include/X11/Xlib.h:3583: error: syntax error before "_X_SENTINEL"
/usr/include/X11/Xlib.h:3596: error: syntax error before "_X_SENTINEL"
/usr/include/X11/Xlib.h:3609: error: syntax error before "_X_SENTINEL"
/usr/include/X11/Xlib.h:3614: error: syntax error before "_X_SENTINEL"
/usr/include/X11/Xlib.h:3846: error: syntax error before "_X_SENTINEL"
/usr/include/X11/Xlib.h:3850: error: syntax error before "_X_SENTINEL"
/usr/include/X11/Xlib.h:3862: error: syntax error before "_X_SENTINEL"
/usr/include/X11/Xlib.h:3890: error: syntax error before "_X_SENTINEL"
/usr/include/X11/Xlib.h:3894: error: syntax error before "_X_SENTINEL"
/usr/include/X11/Xlib.h:3934: error: syntax error before "_X_SENTINEL"
make[5]: *** [XpAttr.o] Error 1
make[5]: *** [XpAttr.o] Error 1
make[5]: Leaving directory `/home/mexon/courier/libgl1-mesa-dev/xfree86-4.3.0/build-tree/xc-xserver-xfree86-dbg/lib/Xp'
make[4]: *** [all] Error 2
make[4]: Leaving directory `/home/mexon/courier/libgl1-mesa-dev/xfree86-4.3.0/build-tree/xc-xserver-xfree86-dbg/lib'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/mexon/courier/libgl1-mesa-dev/xfree86-4.3.0/build-tree/xc-xserver-xfree86-dbg'
make[2]: *** [World] Error 2
make[2]: Leaving directory `/home/mexon/courier/libgl1-mesa-dev/xfree86-4.3.0/build-tree/xc-xserver-xfree86-dbg'
make[1]: *** [World] Error 2
make[1]: Leaving directory `/home/mexon/courier/libgl1-mesa-dev/xfree86-4.3.0/build-tree/xc-xserver-xfree86-dbg'
make: *** [stampdir/build] Error 2
That's probably fixable by removing all X packages before I
start compiling.
Python failed like this:
gcc -pthread -Xlinker -export-dynamic -o python \
Modules/python.o \
libpython2.4.a -lpthread -ldl -lutil -lm
libpython2.4.a(posixmodule.o): In function `posix_tmpnam':./Modules/posixmodule.c:6240: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
libpython2.4.a(posixmodule.o): In function `posix_tempnam':./Modules/posixmodule.c:6195: warning: the use of `tempnam' is dangerous, better use `mkstemp'
case $MAKEFLAGS in \
*-s*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
qemu: uncaught target signal 11 (Segmentation fault) - exiting
make: *** [sharedmods] Error 245
Python was necessary for postgres. So I could try the same
trick for postgres instead.
Actually, I can just apt-get remove libx11-dev. That removes a
whole pile of stuff. But hey, some of those dependencies are
necessary in order to compile xfree86: libxft-dev (>= 2.1.2)
libxrender-dev (>= 0.8.3) libxcursor-dev. And they bring
libx11-dev with them.
OK, I'm installing postgres. Note that it goes under
/usr/local, and the only file there at the moment is
/usr/local/share/texmf/ls-R. Although there are a bunch of
other directories. (bin games include lib man sbin share/man
share/sgml share/texmf share/xml). But it looks like everything
went under /usr/local/pgsql.
Um, here are the entire contents of postgresql-dev (on Aeon):
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/postgresql-dev
/usr/share/doc/postgresql-dev/copyright
/usr/share/doc/postgresql-dev/changelog.gz
Why would anything depend on that?
Despite this progress, I still have many dependencies for
courier. libpcre3-dev libldap-dev libsasl2-dev | libsasl-dev
expect gs | gs-aladdin mgetty-fax netpbm libfam-dev libssl-dev
libpq-dev | postgresql-dev courier-authlib-dev. Start with
libpcre3-dev. "mv pcre-7.4 pcre3-6.7+7.4".
pcre failed like this:
Test 1: main functionality (Perl compatible)
OK
Test 2: API and error handling (not Perl compatible)
qemu: uncaught target signal 11 (Segmentation fault) - exiting
FAIL: RunTest
Testing pcregrep
pcregrep version 6.7.7.4 2007-10-28
Testing pcregrep UTF-8 features
Testing pcregrep newline settings
PASS: RunGrepTest
===================
1 of 5 tests failed
===================
make[2]: *** [check-TESTS] Error 1
Let's try dovecot for a while. Depends on libssl-dev
libldap2-dev postgresql-dev libsasl2-dev | libsasl-dev, which
are also necessary for courier. libssl-dev is apt-gettable.
So next is libldap1-dev. "mv openldap-2.1.30 openldap2-2.1.30".
Depends on libdb4.2-dev libiodbc2-dev libsasl2-dev (>= 2.1.3-1)
debconf-utils libgnutls-dev libgcrypt11-dev. Bugger. Oh wait.
I should be able to do libgcrypt11-dev, now that I've got my
fake dvips in place. If configure doesn't barf. If this works,
it might lead to cups, which might lead to gs.
Yay, libgcrypt is there, at least. Now to gnutls, which depends
on libopencdk8-dev. What is it with these non-executable
debian/rules files? But opencdk8 seems to be going. And it's
installed. So, last dependency for libgnutls is libtasn1-2-dev.
That also has no execute permissions on its rules file.
Oh lovely, I now have libgnutls-dev. Next in the libldap
dependencies is libdb4.2. Which, for the record, is the third
libdb I've done so far. "mv db-4.2.52 db4.2-4.2.52+dfsg". Hmm,
this depends on java-gcj-compat-dev. What the hell? Let's try
the sarge version. "mv db-4.2.52 db4.2-4.2.52". Also depends
on gcj. Bizarre. I think I'll digest that for a bit and move
on to the next dependency, libiodbc2-dev.
"mv libiodbc-3.52.4 libiodbc2-3.52.4". This etch version
depends on a later version of m4, so let's try sarge. "mv
libiodbc-3.52.2 libiodbc2-3.52.2". I needed to get libtool, and
I don't understand why that wasn't already there. Hmm, but this
needs libgtk1.2-dev automake1.6. I have automake1.9 installed,
and libgtk2.0-0. I might try forcing this with -d.
Putting files in AC_CONFIG_AUX_DIR, `admin'.
if [ -d ./m4 ]; then m4="-I m4"; fi; if [ -e ./aclocal.m4 ]; then cd . && aclocal-1.6 $m4; fi
/scratchbox/tools/bin/sh: line 1: aclocal-1.6: command not found
make: *** [debian/stamp-autotools-files] Error 127
OK, I give in, I'll try building automake1.6. Which worked
fine. But libiodbc2 didn't.
Putting files in AC_CONFIG_AUX_DIR, `admin'.
if [ -d ./m4 ]; then m4="-I m4"; fi; if [ -e ./aclocal.m4 ]; then cd . && aclocal-1.6 $m4; fi
aclocal: configure.in: 286: macro `AM_PATH_GTK' not found in library
make: *** [debian/stamp-autotools-files] Error 1
I guess I need libgtk1.2-dev. "mv gtk+-1.2.10 gtk+1.2-1.2.10".
Remind me why a database backend library depends on gtk?
Whatever. I just noticed that my -d flag has been coming along
with all the dpkg-buildpackage commands I've been trying since
way back when. To build libgtk1.2-dev I need libxext-dev
libxi-dev libxmu-dev libglib1.2-dev. And of course that puts me
squarely in xfree86 territory. Oh wait, I can apt-get install
libxext-dev. And libxi-dev. And libxmu-dev. But not
libglib1.2-dev. Not really a surprise.
"mv glib-1.2.10 glib1.2-1.2.10". Damn, that didn't work:
gcc -DHAVE_CONFIG_H -I. -I. -I. -DG_LOG_DOMAIN=g_log_domain_glib -DG_ENABLE_DEBUG -g -O2 -g -Wall -D_REENTRANT -c gstrfuncs.c -fPIC -DPIC -o .libs/gstrfuncs.lo
gstrfuncs.c: In function `g_printf_string_upper_bound':
gstrfuncs.c:870: error: syntax error before string constant
gstrfuncs.c:1037: error: syntax error before string constant
gstrfuncs.c:1080: error: syntax error before string constant
gstrfuncs.c:1111: error: syntax error before string constant
make[3]: *** [gstrfuncs.lo] Error 1
make[3]: Leaving directory `/home/mexon/courier/libglib1.2-dev/glib1.2-1.2.10'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/mexon/courier/libglib1.2-dev/glib1.2-1.2.10'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/home/mexon/courier/libglib1.2-dev/glib1.2-1.2.10'
make: *** [build-stamp] Error 2
There's an etch version I could try. Same version, different
patch. Oh, amazing, that works. So I did that, and gtk1.2, and
now libiodbc2 is compiling. No, it failed at the last step:
dh_installdeb -plibiodbc2-dev
dh_perl -plibiodbc2-dev
dh_shlibdeps -plibiodbc2-dev
dh_gencontrol -piodbc
dpkg-gencontrol: warning: can't parse dependency libiodbc2 libiodbc2-dev
dpkg-gencontrol: error: error occurred while parsing Replaces
dh_gencontrol: command returned error code 2304
make: *** [binary-makedeb-IMPL/iodbc] Error 1
I'll try tweaking that line in the control file to remove
libiodbc2-dev. Yes, that worked.
By the way, I can apt-get install debconf-utils. I'm also
trying libsasl2-dev. "mv cyrus-sasl-2.1.22.dfsg1
cyrus-sasl2-2.1.22.dfsg1". Build dependencies: libdb4.2-dev (>=
4.2.52-24) libmysqlclient15-dev (>= 5.0.20-1) libopie-dev (>=
2.32-10) libpq-dev (>= 8.1.3-4) libkrb5-dev libsqlite0-dev (>=
2.8.16-1) libldap2-dev (>= 2.1.30-8). Yikes. Maybe the sarge
version? Depends on libdb4.2-dev (>= 3.2.9-14) libopie-dev (>=
2.32-8) heimdal-dev (>= 0.4e-16) kerberos4kth-dev (>= 1.1-11)
libmysqlclient10-dev (>= 3.23.52) postgresql-dev libldap2-dev
(>= 2.1.21). I think libldap might have to go in /usr/local.
Even so, it wants db4.2. So maybe that goes in /usr/local too.
Man, it's all fucked up. It tells me to configure in
build_unix, but all that has is a tags link to dist. But if I
try to build inside dist, configure tells me I'm not allowed to.
I'm trying copying everything inside dist into build_unix. No,
that doesn't work. Where the fuck am I supposed to build?
Oh, I can't be helped with my db4.2 problems, but
my
friend is back with help on this cyrus libsasl2 stuff.
The only real problem with etch db4.2 is that it depends on
java-gcj-compat-dev. Which in turn depends on the entire world.
But maybe I can do this. I think gcj has been wrapped up into
gcc, but only past 4.1. So this is another huge undertaking.
Oh, wait, it might be possible to instal gcc in /usr/local too.
No, this is a 3.3 compiler. The installed one is 3.4.4. Close
enough. So there's a chance this might work.
gcc dependencies: dejagnu (>= 1.4.3) expect (>= 5.38.0) gperf
(>= 2.7-3) flex-old | flex (<< 2.5.31) libgc-dev xlibs-dev
gnat-3.3 | gnat-3.2 libgmp3-dev realpath (>= 1.9.12) graphviz
(>= 2.0). xlibs-dev can be apt-gotten. flex seems to be
problematic.
I know. If gcj is part of gcc, then I can apt-get source
gcc-3.4 and try compiling that. It might build the gcj package.
Worth a shot. No, it doesn't build gcj. Maybe I can build
gcc3.4? No, much the same crap: dejagnu (>= 1.4.3) expect (>=
5.38.0) gperf (>= 2.7-3) libgc-dev gnat-3.3 | gnat-3.4
libgmp3-dev libgtk2.0-dev (>= 2.4.4-2) libart-2.0-dev g++-3.3
g77-3.3 gobjc-3.3 realpath (>= 1.9.12) graphviz (>= 2.0)
So what happens if I just try to put gcc (including gcj) 3.4.3
in /usr/local? It fails to compile:
( nm -pg libgcc/./_udivsi3.o | gawk 'NF == 3 && $2 !~ /^[UN]$/ { print "\t.hidden", $3 }'; cat libgcc//stacknote.s ) | /home/mexon/courier/gcj-3.4/gcc-3.4-3.4.3.orig/gcc-3.4.3/gcc/xgcc -B/home/mexon/courier/gcj-3.4/gcc-3.4-3.4.3.orig/gcc-3.4.3/gcc/ -B/usr/local/arm-unknown-linux-gnu/bin/ -B/usr/local/arm-unknown-linux-gnu/lib/ -isystem /usr/local/arm-unknown-linux-gnu/include -isystem /usr/local/arm-unknown-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fomit-frame-pointer -fPIC -g0 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -r -nostdinc -nostdlib -o libgcc/./_udivsi3.oS libgcc/./_udivsi3.o -xassembler -
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/bin/sbox-arm-linux-ld: unrecognised emulation mode: armelf_linux
Supported emulations: armelf_linux_eabi
collect2: ld returned 1 exit status
make[2]: *** [libgcc/./_udivsi3.oS] Error 1
make[2]: Leaving directory `/home/mexon/courier/gcj-3.4/gcc-3.4-3.4.3.orig/gcc-3.4.3/gcc'
make[1]: *** [libgcc.a] Error 2
make[1]: Leaving directory `/home/mexon/courier/gcj-3.4/gcc-3.4-3.4.3.orig/gcc-3.4.3/gcc'
make: *** [all-gcc] Error 2
So instead, I guess my strategy involves patching the Maemo gcc
build to make it build gcj as well. But it was probably taken
out for a reason, so be afraid.
No, this is silly, porting java to a new platform is not even
close to trivial.
Instead, I can try removing the gcj dependency from db4.2. In
the rules file, you get stuff like this:
ifeq (,$(findstring z$(DEB_HOST_GNU_CPU)z,$(JAVA_UNSUPPORTED_CPUS)))
ifeq (,$(findstring z$(DEB_HOST_GNU_SYSTEM)z,$(JAVA_UNSUPPORTED_SYSTEMS)))
JAVA_BIN = /usr/lib/jvm/java-gcj/bin
CONFIGURE_VARS += JAVAC="$(JAVA_BIN)/javac" JAVA="$(JAVA_BIN)/java" JAR="$(JAVA_BIN)/jar"
CONFIGURE_SWITCHES += --enable-java
DB_BINARY_PKGS += libdb4.2-java libdb4.2-java-dev
endif
endif
Aha! If I adjust the control file to say !armel just like it
has !arm, then I might make progress. I think I just need to
update rules and add zarmelz to JAVA_UNSUPPORTED_CPUS. OK, it's
going.
checking if --enable-java option specified... no
With cyrus / libsasl2-dev, I'm going to need a different mysql.
That implies getting the etch mysql to install. This currently
has an unsatisfied dependency on gs. I can try forcing it and
see what breaks.
I have libdb4.2-dev! Yes!
Briefly returning to sarge python, current outstanding
dependencies are tk8.4-dev libgmp3-dev blt-dev (>= 2.4z)
tix8.1-dev (>= 8.1.3.93) emacs21. tk8.4-dev I've already done,
just a question of uninstalling the 8.3 version first. Emacs 22
is installed, that'll do for emacs. Let's work through the
others.
libgmp3-dev. "mv gmp-4.2.1.dfsg gmp-4.2.1+dfsg". Ah, how
refreshing to have something just build.
MySQL failed like this:
if test -f y.output; then \
mv y.output sql_yacc.output; \
fi
sed '/^#/ s|y\.tab\.c|sql_yacc.cc|' y.tab.c >sql_yacc.cct && mv sql_yacc.cct sql_yacc.cc
sed: can't read y.tab.c: No such file or directory
make[3]: *** [sql_yacc.cc] Error 2
make[3]: Leaving directory `/home/mexon/courier/libmysqlclient-dev/mysql-dfsg-5.0-5.0.32.orig/sql'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/mexon/courier/libmysqlclient-dev/mysql-dfsg-5.0-5.0.32.orig'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/mexon/courier/libmysqlclient-dev/mysql-dfsg-5.0-5.0.32.orig'
make: *** [build-stamp] Error 2
I fixed this before, somehow. Something to do with YACC being
undefined. Yes, I hacked the Makefile manually. Previously I
had a problem that the patches couldn't be unapplied. Let's see
if this is still a problem. But wait. How did I force it
before, if I had to extract freshly every time the build failed?
Maybe I can "export YACC=bison".
And libgmp3-dev failed like this:
/.libs/libgmpxx.so /home/mexon/courier/libgmp3-dev/gmp-4.2.1+dfsg/.libs/libgmp.so ../../.libs/libgmp.so
t-locale.o: In function `set_point(char)':/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/bin/../lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../include/c++/3.4.4/bits/locale_facets.h:1682: undefined reference to `std::numpunct::_M_initialize_numpunct(int*)'
collect2: ld returned 1 exit status
make[5]: *** [t-locale] Error 1
make[5]: Leaving directory `/home/mexon/courier/libgmp3-dev/gmp-4.2.1+dfsg/tests/cxx'
make[4]: *** [check-am] Error 2
make[4]: Leaving directory `/home/mexon/courier/libgmp3-dev/gmp-4.2.1+dfsg/tests/cxx'
make[3]: *** [check-recursive] Error 1
make[3]: Leaving directory `/home/mexon/courier/libgmp3-dev/gmp-4.2.1+dfsg/tests'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/home/mexon/courier/libgmp3-dev/gmp-4.2.1+dfsg'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/home/mexon/courier/libgmp3-dev/gmp-4.2.1+dfsg'
make: *** [build-stamp] Error 2
I'll try retreating to sarge. Man, it makes me nervous to see a
build running unit tests. What if they fail? Unit tests suck.
No, it failed again. But I thought it was working because of this:
make[3]: Leaving directory `/home/mexon/courier/libmysqlclient-dev/mysql-dfsg-5.0-5.0.32.orig/vio'
Making all in sql
make[3]: Entering directory `/home/mexon/courier/libmysqlclient-dev/mysql-dfsg-5.0-5.0.32.orig/sql'
bison -d --debug --verbose sql_yacc.yy
sql_yacc.yy: conflicts: 249 shift/reduce
But then:
sed '/^#/ s|y\.tab\.c|sql_yacc.cc|' y.tab.c >sql_yacc.cct && mv sql_yacc.cct sql_yacc.cc
sed: can't read y.tab.c: No such file or directory
make[3]: *** [sql_yacc.cc] Error 2
make[3]: Leaving directory `/home/mexon/courier/libmysqlclient-dev/mysql-dfsg-5.0-5.0.32.orig/sql'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/mexon/courier/libmysqlclient-dev/mysql-dfsg-5.0-5.0.32.orig'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/mexon/courier/libmysqlclient-dev/mysql-dfsg-5.0-5.0.32.orig'
make: *** [build-stamp] Error 2
Maybe I never did get this working? No, I definitely did.
This time, libgmp3 fails like this:
PASS: t-bin
mpz_get_d wrong on 2**64
z =18446744073709551616
want 18446744073709551616
got 9223372039002259456
qemu: Unsupported syscall: 268
qemu: Unsupported syscall: 238
qemu: Unsupported syscall: 268
qemu: Unsupported syscall: 238
FAIL: t-get_d
PASS: t-get_si
...
PASS: t-aorsmul
mpz_cmp_d wrong (from check_onebits)
got 1
want 0
x=1
y 1
x=0x1
y 0X1P+0
y 00 00 00 00 00 00 F0 3F
qemu: Unsupported syscall: 268
qemu: Unsupported syscall: 238
qemu: Unsupported syscall: 268
qemu: Unsupported syscall: 238
FAIL: t-cmp_d
PASS: t-cmp_si
...
====================
2 of 53 tests failed
====================
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory `/home/mexon/courier/libgmp3-dev/gmp-4.1.4/tests/mpz'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/home/mexon/courier/libgmp3-dev/gmp-4.1.4/tests/mpz'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/home/mexon/courier/libgmp3-dev/gmp-4.1.4/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/home/mexon/courier/libgmp3-dev/gmp-4.1.4'
make: *** [build-stamp] Error 2
It is just about conceivable that I could compile this on a real
Maemo machine. Frustratingly, the packages are
available here,
but for arm and not armel. I assume there's a good difference.
Oh wow. I may well be wasting my time. I discovered a buch of
packages at this
place, via gronmayer.com. And down comes libgmp3-dev.
Wonderful! What else do they have? Well, python-dev, but I
can't seem to install it. And not much else really. But
libgmp3-dev was a good start!
The likely reason I can't install python-dev is that they're
getting the main python from some other repository.
So, blt-dev. Requires tcl8.4. I've got that. Hmm, no,
requires tk8.3. I haven't done that yet. Careful to get the
version that matches tcl8.3. Well, neither of them do, so I'll
go for etch. "mv tk8.3.5 tk8.3-8.3.5". Lots of confusion as to
which versions of tcl and tk are required, but it's building
now.
Aha! To avoid the cyrus dependency on mysql, this says:
# Circumvent circular dependencies:
# - build cyrus-sasl2 without LDAP support and install libsasl2-dev
# - build openldap2 against the cut-down libsasl2 and install libldap2-dev
# - rebuild and install cyrus-sasl2 with LDAP support
# Patch cyrus-sasl2*/debian/rules to implement DEB_BUILD_OPTIONS, then:
DEB_BUILD_OPTIONS='no-sql no-ldap' build -d cyrus-sasl2
install libsasl2{,-dev}
install autoconf2.13 # builddep of openldap2
# Remove sql support from openldap2, then
build openldap2
install libldap2{,-dev}
remove autoconf2.13 # again!
DEB_BUILD_OPTIONS='no-sql' build -d cyrus-sasl2
install libsasl2{,-dev}
build -d openldap2.3
Just for something to do, libkrb5-dev. Dependencies byacc |
bison ss-dev. How is it that I didn't have bison installed?
ss-dev is also apt-gettable. But for the moment, I'm going to
return to libsasl2, because I realise that there's actually a
patch
on my
friend's page. Patch doesn't quite go, so I'll do it by
hand. Hmm, can't quite find all the places.
--- rules~ 2008-02-15 08:47:18.000000000 +0100
+++ rules 2008-02-15 12:50:19.000000000 +0100
@@ -46,6 +46,23 @@
# Some convenience variables
export TMPPKG := $(CURDIR)/debian/tmp
+# Bootstrapping package-building options
+ifeq (,$(findstring no-sql,$(DEB_BUILD_OPTIONS))
+ SASL_SQL=yes
+ CONFIGURE_SQL=--enable-sql
+else
+ SASL_SQL=no
+ CONFIGURE_SQL=--disable-sql
+endif
+
+ifeq (,$(findstring no-ldap,$(DEB_BUILD_OPTIONS))
+ SASL_LDAP=yes
+ CONFIGURE_LDAP=--with-ldap
+else
+ SASL_LDAP=no
+ CONFIGURE_LDAP=--without-ldap
+endif
+
+
AUTOTOOLS=rm -f acinclude.m4 aclocal.m4 config/config.sub \
config/config.guess config/ltmain.sh config/libtool.m4 && \
libtoolize --force && \
@@ -121,6 +138,8 @@
--enable-plain \
--enable-anon \
--enable-login \
+ $(CONFIGURE_LDAP) \
+ $(CONFIGURE_SQL) \
--enable-ntlm \
--disable-passdss \
--enable-sql \
So then I have to hack up the control file, removing mysql and
ldap, and do:
> export DEB_BUILD_OPTIONS='no-sql no-ldap'
> dpkg-buildpackage -rfakeroot -uc -b
But I still have these unmatched dependencies: libopie-dev (>=
2.32-10) libpq-dev (>= 8.1.3-4) libkrb5-dev libsqlite0-dev (>=
2.8.16-1). I knew there was a reason I was fooling around with
kerberos.
Over in the other terminal, blt-dev installed OK. Next is
tix8.1-dev.
Damn, I really am wasting my time. It's all
done: the Debian
armel port. apt-get courier-imap works. Wow. No, wait,
it's pulling in the whole world. I don't want to do that.
binutils, libc6, all of that has to stay.
So onwards. Opie is going. That's weird. It failed like this:
dh_buildinfo
dh_buildinfo: cannot read /usr/share/build-essential/essential-packages-list: No such file or directory
make: *** [install-stamp] Error 1
Seems I have to apt-get install build-essential. Now I've got
libopie-dev installed. Next, libpq-dev. Wait, that's postgres
again. That needs to be removed too. So lastly, sqlite, wait,
that shouldn't be there either. So I'm only waiting on
kerberos. Which fails in this spookily familiar manner:
bison ../../../src/kadmin/cli/getdate.y
../../../src/kadmin/cli/getdate.y: conflicts: 4 shift/reduce
mv -f y.tab.c getdate.c
mv: cannot stat `y.tab.c': No such file or directory
make[3]: *** [getdate.c] Error 1
make[3]: Leaving directory `/home/mexon/courier/libkrb5-dev/krb5-1.4.4/build/kadmin/cli'
make[2]: *** [all-recurse] Error 1
make[2]: Leaving directory `/home/mexon/courier/libkrb5-dev/krb5-1.4.4/build/kadmin'
make[1]: *** [all-recurse] Error 1
make[1]: Leaving directory `/home/mexon/courier/libkrb5-dev/krb5-1.4.4/build'
make: *** [build-stamp] Error 2
This is probably relevant from the bison manpage:
Input files should follow the yacc convention of ending in .y.
Unlike yacc, the generated files do not have fixed names, but
instead use the prefix of the input file. Moreover, if you
need to put C++ code in the input file, you can end his name by
a C++-like extension (.ypp or .y++), then bison will follow
your extension to name the output file (.cpp or .c++). For
instance, a grammar description file named parse.yxx would
produce the generated parser in a file named parse.tab.cxx,
instead of yacc's y.tab.c or old Bison version's parse.tab.c.
Note that I actually have ./build/kadmin/cli/getdate.tab.c. And
note that I still have YACC set. Maybe I shouldn't.
While I try that again, let's review. The only outstanding
dependencies for dovecot are ldap, sasl and postgres. Courier
has some other dependencies too. So I definitely need to get
postgres compiled. But I'm prepared to install it behind
Debian's back. Oh, and bear in mind that in fact I've already
done that. So ldap and sasl are the only ones left. sasl's
only dependency is kerberos, which I'm compiling now. ldap I
appear to also be compiling behind Debian's back. And the only
reason I didn't do that is that it needed libdb4.2-dev, which
I've got installed. I might be able to try the Debian way
again. It's only waiting for libsasl2-dev. So here's what's
left:
- libkrb5-dev
- libsasl2-dev
- libldap2-dev
- dovecot
And kerberos just worked. Light at the end of the tunnel!
My patch to cyrus doesn't seem to work. So screw it, I'll
hard-wire it. Man, it's slow. No!
checking for gsskrb5_register_acceptor_identity... no
checking to use mutexes aroung GSS calls... yes
checking PLAIN... enabled
checking ANONYMOUS... enabled
checking LOGIN... enabled
checking NTLM... enabled
checking PASSDSS... disabled
checking SQL... enabled
checking for mysql_select_db in -lmysqlclient... yes
checking for PQsetdbLogin in -lpq... no
configure: WARNING: PostgreSQL Library pq does not work
configure: WARNING: SQLite Library not found
checking LDAPDB... enabled
checking ldap.h usability... no
checking ldap.h presence... no
checking for ldap.h... no
checking lber.h usability... no
checking lber.h presence... no
checking for lber.h... no
checking OpenLDAP version... no
configure: error: Cannot enable LDAPDB plugin: OpenLDAP library located but incompatible
make: *** [config.status] Error 1
No, wait, with a little more hard-wiring I can fix this. No
again, I can't. The --without-ldap and --disable-sql flags are
right there in the configure line that was run.
Maybe it detected my dodgy install in /usr/local? Maybe in fact
I have to uninstall everything to do with SQL. Aha!
Not --without-ldap, --disable-ldap. Nope, still broken. Damn.
Clearly --without-ldap is actually a synonym for --disable-ldap.
No, wait! What's this switch?
...
--disable-ldap \
--disable-sql \
--enable-ntlm \
--disable-passdss \
--enable-sql \
--enable-ldapdb \
...
Gah! I'd been re-enabling both SQL and LDAP all along. Also,
ldap has been renamed ldapdb. Yes, and now we're cooking with
gas! My friend, you had better fucking compile, that's all I
can say.
Oooh! So close, and yet so far:
mv /home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp/usr/share/man/man8/pluginviewer.8 \
/home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp/usr/share/man/man8/saslpluginviewer.8
install -m 644 saslauthd/saslauthd.mdoc \
/home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp/usr/share/man/man8/saslauthd.8
install -m 644 /home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/testsaslauthd.8 \
/home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp/usr/share/man/man8/testsaslauthd.8
mv /home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp/usr/sbin/dbconverter-2 /home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp/usr/sbin/sasldbconverter2
install -m 644 utils/sasldbconverter2.8 \
/home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp/usr/share/man/man8/sasldbconverter2.8
# Install sample-{client,server} with Debianized names
install -m 755 -D /home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/sample/sample-client \
/home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp/usr/bin/sasl-sample-client
install -m 755 -D /home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/sample/sample-server \
/home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp/usr/sbin/sasl-sample-server
# Alter the rpath of certain binaries and shared libraries.
chrpath -d /home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp/usr/sbin/sasldblistusers2 \
/home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp/usr/sbin/saslpasswd2
chrpath -d /home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp/usr/lib/sasl2/libsql.so.2.0.22
open: No such file or directory
elf_open: Illegal seek
make: *** [install] Error 1
Luckily, I know this one. This was a bit that I missed out of
the patch:
rules: chrpath -d $(TMPPKG)/usr/lib/sasl2/libsql.so.2.0.22
We're way, way beyond the niceties here. No #if whatevers for
me. Delete that motherfucker.
Curse!
dh_installdocs -a
dh_installexamples -a
dh_installdirs -a
dh_install -a --autodest --list-missing --sourcedir=/home/mexon/courier/libsasl2-dev/cyrus-sasl2-2.1.22.dfsg1/debian/tmp
dh_install: libsasl2-modules-ldap missing files (usr/lib/sasl2/libldapdb.*), aborting
make: *** [binary-arch] Error 1
I need to edit the control file to remove libsasl2-modules-ldap.
And hey, while I'm there, why not delete libsasl2-modules-sql as
well?
Ladies and gentlemen, libsasl2-dev is installed. And there
was much fucking rejoicing.
openldap is compiling. Not for very long though:
checking for ltdl.h... no
configure: error: could not locate libtool ltdl.h
On Aeon that comes from libltdl3-dev. But if I want to compile
that, that's libtool. I don't want to compile that. I think a
retreat to sarge is in order. Hmm, same tarball, different
diff. Which was I using? Well, this time I'm using the sarge
version, openldap2_2.1.30-8.diff. Yes, and that fails. So
etch? That's openldap2_2.1.30-13.3.diff. Same problem. So I
really need to figure out what's up with libtool.
apt-get source libtool. Wow, requires g77 in order to compile.
Which isn't available. Curse. Why am I dependent on Fortran?
Who writes code in Fortran?
Maybe I could compile gcc now? Depends on libgc-dev and
realpath. Realpath at least is easy to compile. libgc-dev
next: "mv gc6.8 libgc-6.8". At least there are no dependencies
to chase. But depending on being able to compile gcc is a very
fragile dependency path. No, libgc-dev segfaults during its
tests.
qemu: uncaught target signal 11 (Segmentation fault) - exiting
FAIL: gctest
qemu: uncaught target signal 11 (Segmentation fault) - exiting
FAIL: test_cpp
==================================
2 of 2 tests failed
Please report to Hans.Boehm@hp.com
==================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/home/mexon/courier/libgc-dev/libgc-6.8'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/home/mexon/courier/libgc-dev/libgc-6.8'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/home/mexon/courier/libgc-dev/libgc-6.8'
make: *** [install-stamp] Error 2
I'm starting to get a little sick of qemu. This one is small
enough that I may be able to get away with compiling it on the
n810. Course, that'll involve 16MB of downloads, so best to
lose emacs for now.
Just to mark time: I now have 517 .debs. Wowee. Woah!
Including g77! How did that happen? Oh, yeah, I can't install
it. It's only an empty package.
From this
IRC
log, this
page.
It's also important that I get aptitude. Dependencies:
libapt-pkg-dev (>= 0.6.0) libsigc++-2.0-dev libcppunit-dev po4a.
apt-get source apt is a nicely recursive command.
Well. Compiling on the n810 didn't go very well:
dpkg-buildpackage: source version without epoch 6.8-1
fakeroot debian/rules clean
Segmentation fault
sh: bad signal name 's'
Meanwhile, libsigc++-2.0-dev didn't work either:
dh_testroot
if [ -d builddir ]; then rm -rf builddir; fi
#-for x in debian/*.patch; do patch --dry-run -fRp1 < $x > /dev/null&&\
# patch -fRp1 < $x ; done
dh_clean build-stamp config-stamp install-stamp debian/shlibs.local
debian/rules build
dh_testdir
#for x in debian/*.patch; do patch --dry-run -fp1 < $x > /dev/null && \
# patch -fp1 < $x; done
test -d builddir || mkdir builddir
cd builddir && ../configure --prefix=/usr
/scratchbox/tools/bin/sh: line 1: ../configure: No such file or directory
make: *** [config-stamp] Error 127
Before I worry about that, it's worth noting that I was going to
compile cups. But it still depends on libldap2-dev. So I'm
still stuck.
Googling for maemo and g77 got me to here.
Unpacking g77-3.4 (from g77-3.4_3.4.4cs2005q3.2-5.osso3_armel.deb) ...
dpkg: dependency problems prevent configuration of g77-3.4:
g77-3.4 depends on gcc-3.4-base (= 3.4.4cs2005q3.2-5.osso3); however:
Version of gcc-3.4-base on system is 3.4.4cs2005q3.2-5.osso8.
g77-3.4 depends on gcc-3.4 (= 3.4.4cs2005q3.2-5.osso3); however:
Version of gcc-3.4 on system is 3.4.4cs2005q3.2-5.osso8.
dpkg: error processing g77-3.4 (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
g77-3.4
It would appear to be an all-or-nothing deal.
While I wait for that to fetch, I got the various apt packages
compiled and installed.
No, that herring g77 is i386! Ah, no, wait, it's a mixture.
Installing just the armel ones works. And I have g77. Um.
Yay!
cppunit depends on libqt3-mt-dev libqt3-compat-headers. Of
course! Why on earth would it not depend on qt? Nokia loves
qt, so I hear. At least libtool is going. Ah crap, it's
testing itself. I hate it when they do that.
QT is sooooo not an option, not with all those X dependencies.
Jesus Christ libtool, would you please stop testing
yourself? You're gonna give me a heart attack. No-one cares
whether you actually work or not, we just want you installed.
You're not being big, or clever, you know.
Since that's going on, I might as well package up isync, since
that was kinda the point. Depends on libssl-dev. Oh yes, that
must be apt-gettable. Except that right now, nothing's
apt-gettable:
The following packages have unmet dependencies:
apt-utils: Depends: libapt-pkg-libc6.4-6-3.11
libapt-pkg-dev: Depends: libapt-pkg-libc6.4-6-3.11
Holy crap! I now have libltdl3-dev! Quick, before it wanders
away again! Man, look at all that history rolling past me.
db-4.2, sasl, readline, crypt. All my blood, sweat and tears.
And now it has graciously condescended to start compiling.
Let's see how far it gets.
I resolved my apt hell like this:
dpkg --remove libapt-pkg-dev
dpkg --remove apt-utils
apt-get install libapt-pkg-libc6.4-6-3.11
libssl-dev is still at the latest version though.
openldap is very much not compiling:
cc -Wall -g -D_FILE_OFFSET_BITS=64 -O2 -I../../include -I/home/mexon/courier/libldap2-dev/openldap2-2.1.30/include -DLDAP_LIBRARY -c /home/mexon/courier/libldap2-dev/openldap2-2.1.30/libraries/libldap/tls.c -fPIC -DPIC -o .libs/tls.o
In file included from /home/mexon/courier/libldap2-dev/openldap2-2.1.30/libraries/libldap/tls.c:38:
/home/mexon/courier/libldap2-dev/openldap2-2.1.30/include/ldap_pvt_gnutls.h:126: error: syntax error before "gnutls_certificate_credentials_t"
/home/mexon/courier/libldap2-dev/openldap2-2.1.30/include/ldap_pvt_gnutls.h:126: warning: no semicolon at end of struct or union
/home/mexon/courier/libldap2-dev/openldap2-2.1.30/include/ldap_pvt_gnutls.h:130: error: syntax error before '}' token
This puts me in a bit of a bind. First, I guess I should revert
to the usual gcc.
The following packages have been kept back:
cpp-3.4 g++-3.4 gcc-3.4 gcc-3.4-base libg2c0 libg2c0-dev libreadline5 libstdc++6 libstdc++6-dev python
The following packages will be upgraded:
bash iptables iptables-dev libgcc1 libgcrypt11 libgcrypt11-dev libgpg-error0 ucf
8 upgraded, 0 newly installed, 0 to remove and 10 not upgraded.
Need to get 1635kB of archives.
After unpacking 1122kB of additional disk space will be used.
Do you want to continue [Y/n]?
No, no that's no good. I don't want those things held back. So
let's try removing them and reinstalling them. No, that doesn't
work either. apt-get install cpp-3.4 is enough.
So. Let's try trashing the package and using the sarge diff.
If that also fails, then I could try going for a different
version of... wait. tls.c comes from libssl-dev? Didn't I only
just now install that? No, I failed to install it.
Maybe I shouldn't be trusting the Nokia libssl-dev.
I think it's getting further this time. Does servers
come after lib? Because it's compiling servers. Man, there
sure are a lot of warnings.
I can't cope with watching that. Let's see what's left for
courier. Um, lots of stuff. Let's see about expect. I've
probably given up recording the "mv expect-5.43 expect-5.43.0"
stuff by now, haven't I?
No, ldap has only just started compiling its libraries.
Or... maybe it's installing stuff?
Actually, I'm a little freaked. Let's make a backup.
ldap built! And installed! Wow! Definitely time to
make a backup.
Right, so the only problem with dovecot now is postgres, but
I've got that in /usr/local. So I can force it.
Meanwhile, I'm compiling cups.
And there it is! I've got dovecot-imapd. But I can't actually
install it in scratchbox. It wants adduser, and there's
something going on with "cannot set hostname to -s". I might
need the hostname package, and I might need the adduser package,
and I might need both of those to be dependencies of dovecot.
Except that this will conflict with busybox. That might be a
problem.
Ah, OK. I just need to patch dovecot-common.postinst and remove
the -s flag. But what about -f? According to the documentation
for busybox, both -s and -f work. What version am I using?
Interestingly, on the Nokia, both -s and -f yield
"Nokia-N810-50-2". I wonder if that will do?
adduser definitely needs to be a dependency of dovecot. I
brought it in to support fuse.
Apropos fuse, this is interesting:
/home/user # apt-get install --reinstall makedev
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 2 not upgraded.
Need to get 38.7kB of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue [Y/n]? y
WARNING: The following packages cannot be authenticated!
makedev
Install these packages without verification [y/N]? y
Get:1 http://repository.maemo.org chinook/free makedev 2.3.1-73osso-4 [38.7kB]
Fetched 38.7kB in 0s (62.1kB/s)
dpkg: syntax error: unknown group `fuse' in statoverride file
E: Sub-process /usr/bin/dpkg returned an error code (2)
/home/user # ls -l /dev/
/home/user # grep fuse /etc/group
/home/user # groupadd fuse
/home/user # apt-get install --reinstall makedev
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 2 not upgraded.
Need to get 0B/38.7kB of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue [Y/n]? y
WARNING: The following packages cannot be authenticated!
makedev
Install these packages without verification [y/N]? y
(Reading database ... 22270 files and directories currently installed.)
Preparing to replace makedev 2.3.1-73osso-4 (using .../makedev_2.3.1-73osso-4_all.deb) ...
Unpacking replacement makedev ...
Setting up makedev (2.3.1-73osso-4) ...
/home/user # groupdel fuse
I think all trace of fuse is gone, though. In fact, I think
I've now restored the n810 to sanity. The reason I did that is
that it's time to think about setting up a proper repository for
all this stuff.
First, I guess this is going under apt.exon.name.
alice:~# mkdir -p /var/www/apt
alice:~# mkdir -p /var/www/apt/conf
alice:~# mkdir -p /var/www/apt/incoming
alice:~# vi /var/www/apt/conf/distributions
alice:~# cat /var/www/apt/conf/distributions
Origin: Matthew Exon
Label: Maemo Development Ports
Suite: unstable
Codename: chinook
Version: 4.0
Architectures: armel all source
Components: main non-free contrib
Description: This is an extremely unstable and hacked up bunch of packages. Use them for bootstrapping your development environment so that you can build other packages, and nothing else!
alice:~# chown -R mat.mat /var/www/apt
Cups built, by the way. Pretty much an anti-climax by now.
So apparently that's all the setup I need for that apt stuff.
Except of course I need to get the webserver actually
configured, but that's apparently not necessary in order to get
stuff in the archive. So let's try uploading dovecot. Hmm, I
have a .changes file for that. I can probably do a source
upload, I don't have to do a binary one. But we'll start with a
binary upload.
mat@alice:/var/www/apt$ reprepro -Vb . include chinook ~/dovecot_0.99.14-1sarge0_all.deb
Created directory "./db"
include called with a file not ending with '.changes'
(Did you mean includedeb or includedsc?)
To ignore use --ignore=extension.
There have been errors!
OK then, I'll upload that.
mat@alice:/var/www/apt$ reprepro -Vb . include chinook ~/dovecot_0.99.14-1sarge0_armel.changes
WARNING: Distribution chinook contains an architecture called 'all'.
WARNING: Distribution chinook contains an architecture called 'all'.
WARNING: Distribution chinook contains an architecture called 'all'.
Data seems not to be signed trying to use directly...
.changes put in a distribution not listed within it!
To ignore use --ignore=wrongdistribution.
Exporting indices...
Created directory "./dists"
Created directory "./dists/chinook"
Created directory "./dists/chinook/main"
Created directory "./dists/chinook/main/binary-armel"
Created directory "./dists/chinook/main/binary-all"
Created directory "./dists/chinook/main/source"
Created directory "./dists/chinook/non-free"
Created directory "./dists/chinook/non-free/binary-armel"
Created directory "./dists/chinook/non-free/binary-all"
Created directory "./dists/chinook/non-free/source"
Created directory "./dists/chinook/contrib"
Created directory "./dists/chinook/contrib/binary-armel"
Created directory "./dists/chinook/contrib/binary-all"
Created directory "./dists/chinook/contrib/source"
There have been errors!
I see. I have to create distributions that match what's in the
.changes file. That's a good thing really. It will force me to
sort them out by their original source.
mat@alice:/var/www/apt$ cat conf/distributions
Origin: Matthew Exon
Label: Maemo Development Ports
Suite: stable-security
Codename: etch
Version: 4.0
Architectures: armel all source
Components: main non-free contrib
Description: This is an extremely unstable and hacked up bunch of packages. Use them for bootstrapping your development environment so that you can build other packages, and nothing else!
Origin: Matthew Exon
Label: Maemo Development Ports
Suite: unstable
Codename: sid
Version: 4.0
Architectures: armel all source
Components: main non-free contrib
Description: This is an extremely unstable and hacked up bunch of packages. Use them for bootstrapping your development environment so that you can build other packages, and nothing else!
mat@alice:/var/www/apt$ reprepro -Vb . include etch ~/dovecot_0.99.14-1sarge0_armel.changes
WARNING: Distribution etch contains an architecture called 'all'.
WARNING: Distribution etch contains an architecture called 'all'.
WARNING: Distribution etch contains an architecture called 'all'.
Data seems not to be signed trying to use directly...
Created directory "./pool"
Created directory "./pool/main"
Created directory "./pool/main/d"
Created directory "./pool/main/d/dovecot"
db: 'dovecot-pop3d' added to 'etch|main|armel'.
db: 'dovecot-imapd' added to 'etch|main|armel'.
db: 'dovecot-common' added to 'etch|main|armel'.
db: 'dovecot' added to 'etch|main|armel'.
db: 'dovecot' added to 'etch|main|all'.
Exporting indices...
Created directory "./dists/etch"
Created directory "./dists/etch/main"
Created directory "./dists/etch/main/binary-armel"
Created directory "./dists/etch/main/binary-all"
Created directory "./dists/etch/main/source"
Created directory "./dists/etch/non-free"
Created directory "./dists/etch/non-free/binary-armel"
Created directory "./dists/etch/non-free/binary-all"
Created directory "./dists/etch/non-free/source"
Created directory "./dists/etch/contrib"
Created directory "./dists/etch/contrib/binary-armel"
Created directory "./dists/etch/contrib/binary-all"
Created directory "./dists/etch/contrib/source"
I guess I'm adding dupload.
gs-esp built, but to install it I need gs-common. We'll see
about that in a minute. Oh, I already did that, but I need to
install both together. And gs is installed! Yay!
Note that the documentation to dupload is wrong. You need to
make that "$config::cfg" instead of "$cfg". Right now, that
fails because I haven't signed my packages. I can figure that
out later.
For reference, unmatched dependencies for courier currently look
like libpcre3-dev mgetty-fax netpbm libfam-dev libpq-dev |
postgresql-dev courier-authlib-dev. I am now confident that I
can sort all of that out. If I can sort out ldap, I'm confident
I can sort out anything.
Except xfree86, obviously.
I can probably compile gs-gpl now. No, that needs libglut-dev,
and that depends on X. To review, xfree86 fails to compile,
while the newer etch X depends on a bunch of stuff including
gcc4. gcc4 depends on autogen dejagnu (>= 1.4.3) expect-tcl8.3
gperf (>= 3.0.1) bison (>= 1:2.3) libmpfr-dev make (>= 3.81)
graphviz (>= 2.2) gsfonts-x11. Hmm, that looks doable. But
superfluous to requirements at the moment.
I don't want to use my own key for these packages. So I'll
disable that check.
$config::cfg{'alice'} = {
fqdn => "alice.exon.name",
login => "[REDACTED]",
method => "scpb",
incoming => "/var/www/apt/incoming/",
# The dinstall on ftp-master sends emails itself
dinstall_runs => 1,
};
delete $config::preupload{'changes'};
1;
I just set up my server, which is nice. But there's no
/etc/apt/sources.list on Joy, so what do I do? Presumably I
need one of these install files. So I hacked up one from
gronmayer.com. But I need to send it as
application/x-install-instructions. That'll take some hackery.
And will involve reading the Apache docs. Yay. Joy is me.
No, I shouldn't be rude, it's pretty straightforward:
AddType application/x-install-instructions .install
I had to restart my browser, but it does at least recognise it
as an install file. But I get the error message "Unable to
install (null). Incompatible application package." Hmm. Maybe
it was a bit much to put three in there? No, that's not it.
Maybe it wants chinook? That'd be annoying. Yes, bingo. A
bora repository produces the same result. OK, time to rethink.
Yes, the reason that's annoying is that I'll have to edit the
.changes files to put them in unstable. But there's no help for
it I guess. Unless there's an option in repropro. Hmm, -C
might be the go.
Sorry, I find this kind of thing hilarious:
--ignore=what
Ignore errors of type what. See the section ERROR IGNORING for possible values.
Sure, yeah, what the hell, why not? --ignore=wrongdistribution
might work. Oh, actually this doesn't seem to be necessary. Or
wait, that's probably because it was unstable anyway. Maybe
dovecot will be different.
.changes put in a distribution not listed within it!
To ignore use --ignore=wrongdistribution.
Now that's an invitation. Now I just need to make it install
packages even if they exist already. Or maybe it doesn't need
to, since it has checksums? Anyway, it's there, let's see if
the n810 can see it. Still doesn't like it!
Dude! What the fuck man! What the fuck?
[Fri Feb 15 18:53:50 2008] [error] [client 219.94.169.84] script '/var/www/apt/thisdoesnotexistahaha.php' not found or unable to stat
[Fri Feb 15 18:53:50 2008] [error] [client 219.94.169.84] script '/var/www/apt/cmd.php' not found or unable to stat
[Fri Feb 15 18:53:51 2008] [error] [client 219.94.169.84] File does not exist: /var/www/apt/cacti
[Fri Feb 15 18:53:51 2008] [error] [client 219.94.169.84] File does not exist: /var/www/apt/portal
[Fri Feb 15 18:53:52 2008] [error] [client 219.94.169.84] File does not exist: /var/www/apt/portal
[Fri Feb 15 18:53:52 2008] [error] [client 219.94.169.84] File does not exist: /var/www/apt/stats
The site's only been up five minutes and some Japanese fucker's
already trying to break in! Are there really people out there
who make scripts called "cmd.php", stick them in the root
directory, and leave script injection holes all over the place?
What are you talking about Mat? Of course there are. If you
were doing this professionally, you'd probably be doing it
yourself.
Fuck. I've just installed wordpress, haven't I? OK, now I'm
scared. You let those PHP s'kiddies fuck with your site, you're
inviting a world of pain man.
So while the entire 12-16-year-old-male demographic of Japan
breaks into my machine, I still haven't actually managed to get
the n810 to recognise my site.
Ah, I get it. OS2008 has a completely different format. Great.
Right, now it works. Except that it complains that it couldn't
see non-free. Hardly surprising, since I only have main so far.
I guess that's all I'll ever have, so I'll get rid of the
others. Good, that seems to work.
/home/user # apt-get install dovecot-imapd dovecot-common
Reading package lists... Done
Building dependency tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
dovecot-common: Depends: libldap2 (>= 2.1.17-1) but it is not going to be installed
Depends: libpam0g (>= 0.76) but it is not installable
Depends: libsasl2-2 but it is not installable
Depends: libpam-runtime (>= 0.76-13.1) but it is not installable
E: Broken packages
OK, that felt really nice. I just duploaded, ran my
incoming-packages script, ran apt-get update, and lost one of my
missing Depends. Again! Again!
Oh baby!
/home/user # apt-get install dovecot-imapd
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
dovecot-common libldap2 libmysqlclient12 libpam-runtime libpam0g libsasl2-2
mysql-common openssl
Suggested packages:
libpam-doc ca-certificates
Recommended packages:
libsasl2-modules
The following NEW packages will be installed:
dovecot-common dovecot-imapd libldap2 libmysqlclient12 libpam-runtime
libpam0g libsasl2-2 mysql-common openssl
0 upgraded, 9 newly installed, 0 to remove and 5 not upgraded.
Need to get 1563kB of archives.
After unpacking 3445kB of additional disk space will be used.
Do you want to continue [Y/n]?
It'd be fun, but no. No, not this time. I still need to add
that dependency on adduser.
Nevertheless, I hereby declare this exercise succesful. And you
thought I was wasting my time, didn't you? Hah! That's all I
have to say to you. Hah!
Anyway. Outstanding dependencies of emacs are mailx
libungif4-dev xaw3dg-dev libxaw7-dev imagemagick libgtk2.0-dev.
Oh come on, I've got libgtk2.0-dev, don't I? Well it's
apt-gettable anyway. And imagemagick, is way gettable.
I just had to google for the repository, which was here.
mailx seems prepared to compile now. That's weird. Didn't this
depend on an MTA or something? Oh, yes, that's right, to
install not to compile. Hmm, but xmail only failed because I
had lsb installed. I can just remove it. Problem solvered.
[sbox-CHINOOK_ARMEL: ~/emacs/xmail] > dpkg --install xmail_1.22-5_armel.deb
(Reading database ... 38775 files and directories currently installed.)
Unpacking xmail (from xmail_1.22-5_armel.deb) ...
Setting up xmail (1.22-5) ...
/scratchbox/tools/bin/chown: changing ownership of `/var/spool/xmail/spool/local': Operation not permitted
dpkg: error processing xmail (--install):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
xmail
Or, you know, not. That's kinda tricky, since I'm not root
here.
Hmm, but sendmail's prepared to compile.
Ha! Me, three days ago, when I was young and green:
To install mailx, I need mail-transport-agent. What's that
gonna be, maybe postfix? No, scary dependencies. Sendmail
seems OK. Xmail seems smaller though. Seems happy enough.
But conflicts with lsb! Wah! OK, sendmail. For which I need
libdb4.2-dev libldap2-dev libwrap0-dev libsasl2-dev. Well,
libdb4.2 is installed, and I can get the source with apt-get
source.
Tee hee. It's almost too painful, isn't it?
Sendmail compiled, but installing it is a bitch. I need
adduser, certainly. But also procmail | maildrop | deliver. OK
then, let's get procmail. It's going. See, there was a time
when even procmail would have complained about dependencies.
And of course, even as I was typing that:
Testing for memmove, strchr, strpbrk, strcspn, strtol, strstr,
rename, setrgid, setegid, pow, opendir, mkdir, waitpid, fsync,
ftruncate, strtod, strncasecmp, strerror, strlcat,
memset, bzero, and _exit
Determining the maximum number of 16 byte arguments execv() takes
Whoeaaa! This actually can't happen.
You have a look and see if you detect anything uncanny:
*******************************************************
/scratchbox/tools/bin/misc_runner: /scratchbox/devkits/cputransp/bin/qemu-arm-0.8.2-sb2: Argument list too long
*******************************************************
I suggest you take a look at the definition of LDFLAGS*
in the Makefile before you try make again.
make[2]: *** [../autoconf.h] Error 1
make[2]: Leaving directory `/home/mexon/emacs/procmail/procmail-3.22/src'
make[1]: *** [autoconf.h] Error 2
make[1]: Leaving directory `/home/mexon/emacs/procmail/procmail-3.22'
make: *** [build] Error 2
Deliver. KISS. Which takes like 30 seconds. So where the hell
is adduser from? Well, according to /var/lib/apt/lists, it's
from debfarm.free.fr_dists_chinook_user_binary-armel_Packages.
Yep, that works. But sendmail-base is unhappy because it can't
create a group. And I can't build exim for dependencies, but I
really don't care anyway. Clearly nothing's going to compile
Emacs here.
Let's set up a cron job on alice to process incoming packages,
just for the fun of it.
Incidentally, I could build tetex-bin if I had libxaw7-dev |
libxaw-dev libt1-dev (>= 5.0.0-3). The last of which is already
compiled.
Actually, this thing where there is a file created when things
have been uploaded is pretty useful here. Otherwise I'd have no
chance of uploading all the right files.
Oh hooray, I can apt-get libxaw7-dev from somewhere or other.
In fact, there's no reason not to do this:
for i in `find . -name \*.changes`; do dupload -t alice $i; done
tetex-bin just failed, for some reason:
DHAVE_CONFIG_H -I.. -I./../goo -I. -I. -DPDF_PARSER_ONLY -DNO_DECRYPTION -c PSTokenizer.cc
make[2]: DHAVE_CONFIG_H: Command not found
make[2]: [PSTokenizer.o] Error 127 (ignored)
rm -f libxpdf.a
ar rc libxpdf.a Array.o BuiltinFont.o BuiltinFontTables.o CMap.o Catalog.o CharCodeToUnicode.o Decrypt.o Dict.o Error.o FontEncodingTables.o FontFile.o Gfx.o GfxFont.o GfxState.o GlobalParams.o JBIG2Stream.o Lexer.o Link.o NameToCharCode.o Object.o OutputDev.o Outline.o PDFDoc.o Page.o Parser.o PDFDocEncoding.o Stream.o UnicodeMap.o XRef.o Function.o PSTokenizer.o
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/bin/sbox-arm-linux-ar: Array.o: No such file or directory
make[2]: *** [libxpdf.a] Error 1
make[2]: Leaving directory `/home/mexon/courier/tetex-bin/tetex-bin-2.0.2.orig/libs/xpdf/xpdf'
make[1]: *** [libs/xpdf/xpdf/libxpdf.a] Error 2
make[1]: Leaving directory `/home/mexon/courier/tetex-bin/tetex-bin-2.0.2.orig'
make: *** [build-stamp] Error 2
libungif4-dev is apt-gettable, by the way. So as of right now,
the only unmet dependencies of emacs are mailx and xaw3dg-dev.
As of right now, isync is complaining about libssl-dev (>=
0.9.8-1) libdb4.4-dev. Ha! I laugh in the face of libdb*-dev
versions nowadays. Bring it on! Oh, except that this one
depends on java. Ah, but with a quick "!armel" and a "zarmelz",
Mat fixes that little obstacle.
Hmm.
checking "rpcgen -C" build of db_server.h... no
checking "rpcgen" build of db_server.h... no
configure: error: Unable to build RPC support: rpcgen failed.
make: *** [build] Error 1
rpcgen belongs to libc6-dev, at least on Alice.
[sbox-CHINOOK_ARMEL: ~/courier/libdb4.4-dev/db4.4-4.4.20] > rpcgen
/scratchbox/tools/alien_bin/rpcgen.bin: error while loading shared libraries: /scratchbox/tools/alien_bin/rpcgen.bin: cannot open shared object file: No such file or directory
What do you reckon, yet another "won't compile under scratchbox"
package? This
suggests a solution:
Firstly we need to copy our existing rpcgen and localedef
binaries into scratchbox so that they can be found and
executed when inside scratchbox. Scratchbox does have its own
rpcgen but you'll find that it segfaults.
# As root on your x86 system:
( cd /usr/bin
cp -fa rpcgen localedef /scratchbox/alien_tools/
/scratchbox/tools/bin/alien_tool_links )
Well great, but I don't have alien_tools. I'm going to
do this:
aeon:/usr/bin# cp rpcgen /scratchbox/tools/bin/rpcgen
Yes, it's compiling now.
Lest we forget, I don't have courier yet. Outstanding
dependencies: libpcre3-dev mgetty-fax netpbm libfam-dev
libpq-dev | postgresql-dev courier-authlib-dev. pcre has qemu
problems. But it's apt-gettable now! Yay!
Can anyone remember how it is that I have a bunch of clisp debs
that I don't remember building? Do they work, or what? (No,
they're for x86).
Oh well, mgetty's built. Installing it requires cron. Not only
do I not have cron, it's not apt-gettable. Um, does debianutils
really replace cron? No, I'm thinking that it really doesn't.
Meantime, libdb4.4-dev is ready. Why did I want that again? Oh
yeah, isync. Which still wants a later version of libssl-dev.
I should get the sarge version. Even though that means dropping
below the magic version 1.0 mark.
So. cron is happy except that it wants libselinux1-dev. That
smells like an etchism to me. Same tarball in sarge though.
No, it too depends on that.
isync built. How nice.
libselinux1-dev depends on: libsepol1-dev (>= 1.14)
python-all-dev (>= 2.3.5-11) swig.
Just having another go at python, the sarge version. For
reference, the only unmet dependency is emacs21, which of course
I've really got. Last I noted, it didn't seem to have its build
dependencies satisfied. It does now. I'm not expecting it to
compile though.
libsepol1-dev is ready. That leaves swig. "mv swig-1.3.29
swig1.3-1.3.29". Whee, check out the dependencies: python-dev
(>= 2.4) python-dev (<< 2.5) ruby1.8 ruby1.8-dev guile-1.6-dev
php4-dev php4-cgi pike7.6 pike7.6-dev ocaml libchicken-dev gcj
gij. I'll bet there's a switch in the control file. Indeed, I
just add armel. And all I have to worry about is, like, ruby.
Meanwhile, python failed with our favourite error message:
case $MAKEFLAGS in \
*-s*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../setup.py -q build;; \
*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../setup.py build;; \
esac
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
sem_post: Function not implemented
qemu: uncaught target signal 11 (Segmentation fault) - exiting
make[1]: *** [sharedmods] Error 245
make[1]: Leaving directory `/home/mexon/courier/python-dev/python2.3-2.3.5.orig/build-static'
make: *** [stamp-build-static] Error 2
This is also how python2.4 failed the last time I tried.
For my next project, I could try to get the newer xorg stuff
working, work through its massive chain of dependencies
including gcc4. First up is autogen, which depends on guile1.6.
Which is apt-gettable. Now. Except that the dev part isn't.
Curse. But for tonight, I'm done.
No I'm not. I think the answer lies here,
where there is all kinds of python stuff, including dev
packages. I just installed python2.5-dev. Just like that. So
what was waiting on python? Looks like it was pretty much just
postgres. So that's a bit of a dead end. Extras doesn't have
gcc4, more's the pity. So, can I build postgres now? Well,
it's going anyway. I'll leave that overnight.
I slept about two hours. That's just not healthy man. I'm
going to be emotionally unstable today. Keep metal cutlery out
of reach.
Postgres failed like this:
arm-linux-gnueabi-gcc -g -O2 -DCHECK_RLIMIT_NOFILE -fno-strict-aliasing -g -pipe -D_GNU_SOURCE -fPIC -shared -Wl,-soname,libplperl.so.0 plperl.o eloglvl.o SPI.o -L../../../src/port -L/usr/local/lib /scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a -L/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -o libplperl.so.0.0
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/bin/../lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../arm-none-linux-gnueabi/bin/ld: /scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a(DynaLoader.o): Relocations in generic ELF (EM: 3)
/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[4]: *** [libplperl.so.0.0] Error 1
make[4]: Leaving directory `/home/mexon/courier/postgresql-dev/postgresql-7.4.7/build-tree/postgresql-7.4.7/src/pl/plperl'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/mexon/courier/postgresql-dev/postgresql-7.4.7/build-tree/postgresql-7.4.7/src/pl'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/mexon/courier/postgresql-dev/postgresql-7.4.7/build-tree/postgresql-7.4.7/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/mexon/courier/postgresql-dev/postgresql-7.4.7/build-tree/postgresql-7.4.7'
make: *** [build-arch-stamp] Error 2
I had that before with eperl. This is probably similar to the
rpcgen thing. Clearly,
i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a is indeed
the wrong architecture.
Anyway, let's fix the adduser dependency of dovecot. The
adduser line is in dovecot-common.postinst, so dovecot-common
gets the dependency. Before I can build I have to install
libldap2 and libsasl2, which went away at one point, but now I
can grab them from my own repository. I still have to force
postgresql-dev.
I think it's time to sort out repositories, which I should have
done, oh, about a week ago. 1) I realise that I should have a
deb-src of etch and sarge, so I don't have to keep patching
manually. It's really embarrassing that I didn't notice this
until now, but hey, it was working, I didn't want to mess with
the rythym. And 2), I should have all the repositories on
gronmayer.com set up. I don't know how much of my work this
makes redundant, but probably a fair whack. Like, for example,
libpq-dev, which just came down. But there's no postgresql-dev.
OK, someone must have it. Let's get gronmayer. I think I was
avoiding that because it's not in any kind of accessible
sources.list format. But Emacs will fix that.
Bizarrely, gronmayer doesn't make it possible to install
postgresql-dev.
Uploading the new dovecot isn't working - reprepro doesn't
replace the existing one. I'll have to remove the old one. But
still, it knows about the old MD5, and isn't happy. I need
either retrack or clearvanished.
No, I see, I hadn't removed dovecot and dovecot-pop3d.
Now it's complaining about missing the original tarball. I
think that's because it hadn't changed. I should delete the
.changes and .upload files and rebuild.
No, I'm still confused. The tarball isn't included in the
upload list. But it wasn't included in any of the others
either. And I have the same problem with isync.
--ignore=missingfile doesn't help: it just looks "elsewhere".
OK, one way or another I've installed isync. Let's try dovecot.
But this time, I'll move them out of the incoming directory
before they get deleted, because that's confusing me. Yeah,
even with --ignore=missingfile, it still insists on having the
tarball. If I upload the tarball to my home directory and use
--ignore=missingfile, it works, but not without
--ignore=missingfile. So I wonder how many other packages
refused to upload?
Anyway, dovecot is now correctly dragging down adduser. In
fact:
The following NEW packages will be installed:
adduser dovecot-common dovecot-imapd libldap2 libmysqlclient12
libpam-runtime libpam0g libsasl2-2 mysql-common openssl
Well, that install isn't going to work:
Setting up dovecot-imapd (0.99.14-1sarge0) ...
sed: /etc/inetd.conf: No such file or directory
I don't have an inet server. That's no good.
So I'm a bit confused about this. There seem to be two
candidates for inetd. Either openbsd-inetd or inetutils-inetd.
One definitely uninstalls the other. But I can't see how I
depend on one or the other. Ah, when I look in
/var/lib/apt/lists, I can see that it provides inet-superserver.
That's what I need to depend on.
I need to rebuild dovecot now. For the hell of it, why not
touch the tarball, see if that makes a difference? And delete
the .changes and .upload files.
I have two tarballs in my pool: dovecot and mailx. Why those
two? No idea.
Wait, I think I see a possibility. Maybe the presence of
.diff.gz files triggers reprepro into believing it must be a
source upload? Let's try deleting that line from the .changes
file.
Ignoring as --ignore=wrongdistribution given.
I don't know what to do having a .dsc without a .diff.gz or .tar.gz in 'incoming/dovecot_0.99.14-1sarge0_armel.changes'!
Exporting indices...
There have been errors!
Yep, that confirms it. Hmm, wait:
Architecture-header lists architecture 'source', but no files for this!
To ignore use --ignore=unusedarch.
Exporting indices...
There have been errors!
Fascinating. There's a thing called "Architecture: source".
[sbox-CHINOOK_ARMEL: ~] > find . -name \*.changes | xargs grep Architecture | grep source
./emacs/mailx/mailx_8.1.2-0.20050715cvs-1_armel.changes:Architecture: source armel
./emacs/sendmail/sendmail_8.13.8-3_armel.changes:Architecture: source all armel
./courier/libdb4.4-dev/db4.4_4.4.20-8_armel.changes:Architecture: source armel all
./courier/libsepol1-dev/libsepol_1.14-2_armel.changes:Architecture: source armel
./dovecot/dovecot/dovecot_0.99.14-1sarge0_armel.changes:Architecture: source armel all
You will notice that db4.2 uploaded OK, but db4.4 didn't.
sendmail isn't there, and neither is libsepol.
More interesting. I just, for the sake of interest, diffed the
original diff I got for dovecot with my diff. And the only diff
diffs were the depends things I just did. In other words, the
diff has changed checksum, and therefore it needs to be
uploaded. Therefore, it must be a source upload. So in other
words, any time I mess with the control file, I'm likely to get
this problem. But I messed with lots of control files, didn't
I? Maybe if I hide the original diff.
dpkg-genchanges
dpkg-genchanges: not including original source code in upload
dpkg-buildpackage: binary and diff upload (original source NOT included)
Good, that looks better. No, dovecot was still built with a
source architecture. I'll mull on that one.
By the way, since copying over my apt-src lines, I can apt-get
source now. inetutils-inetd depends on libshishi-dev. Which
isn't apt-gettable. That depends on libidn11-dev libtasn1-3-dev
(>= 0.3.5). The former (international domain names?) isn't
gettable, but the latter is. Although it argues with emacs when
I try to install it. So remove emacs. libidn wants gengetopt.
Which, finally, is prepared to build without further complaints.
New strategy for dovecot. Let's trash it, apt-get source, and
try again from scratch. Interestingly, in the Etch version
adduser is already a dependency. But inetd isn't yet.
gengetopt failed like this:
g++ -g -Wall -O2 -o gengetopt parser.o scanner.o argsdef.o cmdline.o gengetopt.o gm.o yyerror.o gm_utils.o fileutils.o acceptedvalues.o ggos.o -lfl skels/libgen.a -lfl
/usr/lib/gcc/arm-none-linux-gnueabi/3.4.4/libstdc++.so: undefined reference to `_Unwind_GetDataRelBase@GCC_3.0'
/usr/lib/gcc/arm-none-linux-gnueabi/3.4.4/libstdc++.so: undefined reference to `_Unwind_GetTextRelBase@GCC_3.0'
collect2: ld returned 1 exit status
make[4]: *** [gengetopt] Error 1
make[4]: Leaving directory `/home/mexon/courier/gengetopt/gengetopt-2.18/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/mexon/courier/gengetopt/gengetopt-2.18/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/mexon/courier/gengetopt/gengetopt-2.18'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/mexon/courier/gengetopt/gengetopt-2.18'
make: *** [debian/stamp-makefile-build] Error 2
Let's do the openBSD inetd for a bit. Goes straight away. Gawd
bless ya, openBSD! So the test is, can I install
inet-superserver on the n810?
The following packages have unmet dependencies:
openbsd-inetd: Depends: update-inetd but it is not installable
Looks good to me!
I wonder what emacs' status is then? With my new apt-src, I'll
try just going for emacs21. Depends on mailx xaw3dg-dev
libpng3-dev. mailx is apt-gettable - from myself! And remember
that I couldn't install sendmail because of scratchbox problems.
Dovecot fails like this:
make[4]: Entering directory `/home/mexon/dovecot/dovecot/dovecot-1.0.rc15/dovecot-sieve/src/libsieve'
/bin/sh ../../ylwrap addr.y y.tab.c addr.c y.tab.h addr.h y.output addr.output -- bison -y -d -p addr
../../ylwrap: ../../ylwrap: No such file or directory
make[4]: *** [addr.c] Error 127
make[4]: Leaving directory `/home/mexon/dovecot/dovecot/dovecot-1.0.rc15/dovecot-sieve/src/libsieve'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/mexon/dovecot/dovecot/dovecot-1.0.rc15/dovecot-sieve/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/mexon/dovecot/dovecot/dovecot-1.0.rc15/dovecot-sieve'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/mexon/dovecot/dovecot/dovecot-1.0.rc15/dovecot-sieve'
make: *** [build-stamp] Error 2
I think I now want to add sarge as another apt-src source. But
the question is, how would I then specify it to apt-get? Maybe
-t. No, doesn't seem to help. I just did it the old-fashioned
way. But I still have a source architecture. Oh well.
mat@alice:~$ reprepro -V -b /var/www/apt --ignore=wrongdistribution --ignore=missingfile include chinook dovecot_0.99.14-1sarge0_armel.changes
WARNING: Distribution chinook contains an architecture called 'all'.
WARNING: Distribution chinook contains an architecture called 'all'.
WARNING: Distribution chinook contains an architecture called 'all'.
Data seems not to be signed trying to use directly...
.changes put in a distribution not listed within it!
Ignoring as --ignore=wrongdistribution given.
Created directory "/var/www/apt/pool/main/d/dovecot"
Data seems not to be signed trying to use directly...
Unable to find /var/www/apt/pool/main/d/dovecot/dovecot_0.99.14.orig.tar.gz!
Looking around if it is elsewhere as --ignore=missingfile given.
db: 'dovecot-pop3d' added to 'chinook|main|armel'.
db: 'dovecot-imapd' added to 'chinook|main|armel'.
db: 'dovecot-common' added to 'chinook|main|armel'.
db: 'dovecot' added to 'chinook|main|armel'.
db: 'dovecot' added to 'chinook|main|all'.
db: 'dovecot' added to 'chinook|main|source'.
Exporting indices...
And if I try to install it?
Unpacking update-inetd (from .../update-inetd_4.27-0.5_all.deb) ...
dpkg: error processing /var/cache/apt/archives/update-inetd_4.27-0.5_all.deb (--unpack):
trying to overwrite `/usr/share/perl5/DebianNet.pm', which is also in package netbase
Ouch. OK, it seems that netbase is a tiny package that sets up
a few configuration things. But the Maemo one has been hacked
up to add cron and update-inetd. I can probably install the
Debian version if I can provide cron and update-inetd as well.
Note that debianutils claims to replace cron. But it conflicts
with busybox. Cron depends on libselinux1-dev. That depends on
swig.
Swig actually requires me to downgrade python below
2.5. I'll figure that out later. Some kind soul seems to have
provided ruby already. But not dev. And ocaml? Someone's
having a laugh. Maybe swig could go in /usr/local. Yes it's
doing all kinds of rubbish with lua and clisp. Those aren't
requirements man.
Swig fails:
g++ -I../Source/Include -I../Source/CParse -I../Source/Include -I../Source/DOH -I../Source/CParse -I../Source/Preprocessor -I../Source/Swig -I../Source/Modules -g -O2 -Wall -W -ansi -pedantic -o eswig CParse/cscanner.o CParse/parser.o CParse/templ.o CParse/util.o DOH/base.o DOH/file.o DOH/fio.o DOH/hash.o DOH/list.o DOH/memory.o DOH/string.o DOH/void.o Modules/allegrocl.o Modules/allocate.o Modules/browser.o Modules/cffi.o Modules/chicken.o Modules/clisp.o Modules/contract.o Modules/csharp.o Modules/directors.o Modules/emit.o Modules/guile.o Modules/java.o Modules/lang.o Modules/lua.o Modules/main.o Modules/modula3.o Modules/module.o Modules/mzscheme.o Modules/ocaml.o Modules/overload.o Modules/perl5.o Modules/php4.o Modules/pike.o Modules/python.o Modules/ruby.o Modules/s-exp.o Modules/swigmain.o Modules/tcl8.o Modules/typepass.o Modules/uffi.o Modules/utils.o Modules/xml.o Preprocessor/cpp.o Preprocessor/expr.o Swig/cwrap.o Swig/error.o Swig/fragment.o Swig/getopt.o Swig/include.o Swig/misc.o Swig/naming.o Swig/parms.o Swig/scanner.o Swig/stype.o Swig/symbol.o Swig/tree.o Swig/typeobj.o Swig/typemap.o Swig/typesys.o Swig/warn.o Swig/wrapfunc.o Swig/swigkeys.o -ldl
/usr/lib/gcc/arm-none-linux-gnueabi/3.4.4/libstdc++.so: undefined reference to `_Unwind_GetDataRelBase@GCC_3.0'
/usr/lib/gcc/arm-none-linux-gnueabi/3.4.4/libstdc++.so: undefined reference to `_Unwind_GetTextRelBase@GCC_3.0'
collect2: ld returned 1 exit status
make[2]: *** [eswig] Error 1
make[2]: Leaving directory `/home/mexon/courier/swig/swig-1.3.29/Source'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/mexon/courier/swig/swig-1.3.29/Source'
make: *** [source] Error 2
That looks familiar. gengetopt had the same thing. What a nice person:
Just posting this so anyone looking for this error message can
find it in google.
...
The fix is simply to add -lgcc_s, e.g.
gcc hello.cc -lstdc++ -lgcc_s
OK, not sure exactly where to put it though. I'm going to try
adding it to the LIBS in the Makefile. No, that doesn't help.
Probably not surprising, since strings
/usr/lib/gcc/arm-none-linux-gnueabi/3.4.4/libgcc_s.so doesn't
show it. It does have _Unwind_DeleteException, _Unwind_Resume,
and others. It looks to me like this swig ain't good enough for
3.4.4. I could try the latest tarball from the web.
Failing that, I could try to figure out if one of those Modules
is responsible for the call and try to disable it. Nope, latest
tarball is the same.
g++ -I../Source/Include -I../Source/CParse -I../Source/Include -I../Source/DOH -I../Source/CParse -I../Source/Preprocessor -I../Source/Swig -I../Source/Modules -g -O2 -Wall -W -ansi -pedantic -o eswig CParse/cscanner.o CParse/parser.o CParse/templ.o CParse/util.o DOH/base.o DOH/file.o DOH/fio.o DOH/hash.o DOH/list.o DOH/memory.o DOH/string.o DOH/void.o Modules/allegrocl.o Modules/allocate.o Modules/browser.o Modules/cffi.o Modules/chicken.o Modules/clisp.o Modules/contract.o Modules/csharp.o Modules/directors.o Modules/emit.o Modules/guile.o Modules/java.o Modules/lang.o Modules/lua.o Modules/main.o Modules/modula3.o Modules/module.o Modules/mzscheme.o Modules/ocaml.o Modules/overload.o Modules/perl5.o Modules/php4.o Modules/pike.o Modules/python.o Modules/r.o Modules/ruby.o Modules/s-exp.o Modules/swigmain.o Modules/tcl8.o Modules/typepass.o Modules/uffi.o Modules/utils.o Modules/xml.o Preprocessor/cpp.o Preprocessor/expr.o Swig/cwrap.o Swig/deprecate.o Swig/error.o Swig/fragment.o Swig/getopt.o Swig/include.o Swig/misc.o Swig/naming.o Swig/parms.o Swig/scanner.o Swig/stype.o Swig/symbol.o Swig/tree.o Swig/typeobj.o Swig/typemap.o Swig/typesys.o Swig/warn.o Swig/wrapfunc.o -ldl
/usr/lib/gcc/arm-none-linux-gnueabi/3.4.4/libstdc++.so: undefined reference to `_Unwind_GetDataRelBase@GCC_3.0'
/usr/lib/gcc/arm-none-linux-gnueabi/3.4.4/libstdc++.so: undefined reference to `_Unwind_GetTextRelBase@GCC_3.0'
Anyway, it tells me where the reference is: it's in libstdc++.so. Now:
[sbox-CHINOOK_ARMEL: /usr/lib/gcc/arm-none-linux-gnueabi/3.4.4] > grep GetData *
Binary file libgcc_eh.a matches
Binary file libstdc++.a matches
Binary file libstdc++.so matches
Binary file libsupc++.a matches
But -lgcc_eh doesn't help. Despite:
[sbox-CHINOOK_ARMEL: /usr/lib/gcc/arm-none-linux-gnueabi/3.4.4] > nm libgcc_eh.a
...
unwind-c.o:
U _Unwind_GetDataRelBase
U _Unwind_GetLanguageSpecificData
U _Unwind_GetRegionStart
U _Unwind_GetTextRelBase
U _Unwind_VRS_Get
U _Unwind_VRS_Set
U __aeabi_unwind_cpp_pr0
0000025c T __gcc_personality_v0
U __gnu_unwind_frame
U abort
00000000 t base_of_encoded_value
000000bc t read_encoded_value_with_base
00000094 t read_uleb128
I even tried adding the .a file explicitly to the command line,
but no. Hmm:
[sbox-CHINOOK_ARMEL: /usr/lib/gcc/arm-none-linux-gnueabi/3.4.4] > grep GCC_3.0 *
Binary file libgcc_s.so matches
Binary file libstdc++.so matches
No, I don't think it's anything to do with that. I don't
understand that kind of output, but I guess that these binaries
apply that suffix themselves.
Remind me why I can't build another gcc? Ooh, if Debian won't
let me build a debian gcc 4.1, there's no reason I couldn't
download a tarball, build it myself, and stick it in /usr/local.
I only want it so I can stick something else in
/usr/local. Except there'll probably be some compilation error
or segfault or something.
OK, gcc 4.1, massive dependency hell. But let's try configuring
it nevertheless. Oh, what's the betting that gcc itself manages
to run into the exact same problem I'm trying to solve by
installing it in the first place? Well, for better or worse,
it's compiling. And it failed almost immediately:
../.././fastjar/fastjar.texi:225: Unknown command `gcctabopt'.
../.././fastjar/fastjar.texi:225: Misplaced {.
../.././fastjar/fastjar.texi:225: Misplaced }.
../.././fastjar/fastjar.texi:228: Unknown command `gcctabopt'.
../.././fastjar/fastjar.texi:228: Misplaced {.
../.././fastjar/fastjar.texi:228: Misplaced }.
../.././fastjar/fastjar.texi:229: Unknown command `gcctabopt'.
../.././fastjar/fastjar.texi:229: Misplaced {.
../.././fastjar/fastjar.texi:229: Misplaced }.
makeinfo: Removing output file `fastjar.info' due to errors; use --force to preserve.
make[3]: *** [fastjar.info] Error 1
make[3]: Leaving directory `/home/mexon/courier/gcc/gcc-4.1-4.1.1ds2.orig/gcc-4.1.1/host-arm-unknown-linux-gnu/fastjar'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/mexon/courier/gcc/gcc-4.1-4.1.1ds2.orig/gcc-4.1.1/host-arm-unknown-linux-gnu/fastjar'
make[1]: *** [all-fastjar] Error 2
make[1]: Leaving directory `/home/mexon/courier/gcc/gcc-4.1-4.1.1ds2.orig/gcc-4.1.1'
make: *** [all] Error 2
This is from makeinfo, which presumably comes from texinfo. The
Debian package wanted me to have texinfo >= 4.3. But I do have
4.7-2.2. Here are the dependencies of the Debian way: autogen
dejagnu (>= 1.4.3) expect-tcl8.3 gperf (>= 3.0.1) bison (>=
1:2.3) libmpfr-dev make (>= 3.81) graphviz (>= 2.2) gsfonts-x11.
Can I do all of that? Bear in mind that this is all so I can
have cron installed.
Maybe I can rebuild netbase and say that it provides cron?
Does it, in fact, provide cron? No, not really. So
why does mgetty require cron? It wants to remove itself from
/etc/crontab if it exists, but that seems about it. Since
crontab comes from that hacked up netbase, the grep fails and it
won't bother doing anything else. So you know what? I think
that dependency is a crock too. I'm changing it to "cron |
netbase (= 4.24.osso6)".
I'd forgotten why I was doing that, so a reminder: I couldn't
install mgetty, which was necessary to build courier. For a
moment there I thought it was necessary to install dovecot, but
that's a different netbase conflict, DebianNet.pm. I can
probably fix this somehow. I'm pretty sure that file is there
as a dummy. Well, no actually it does update the inetd.conf
file. Maybe netbase is actually good enough? Maybe I don't
actually need the daemon itself?
Close: should have been "1:4.24.osso6" not "4.24.osso6". Now
mgetty wants logrotate. That's can't be a big deal, surely?
Ha! Depends on libselinux1-dev. Which depends on swig.
OK, so maybe libselinux1-dev could go in /usr/local? It doesn't
have a configure script, just a Makefile. I made it and make
install, and it just shat itself into /usr/sbin. Won't be
getting it out of there again. Lord knows why that was supposed
to depend on swig. Maybe it wants to link with it somehow. But
that was only a build depends. So what happens if I force the
build? Oh, check this out, the very last change:
libselinux (1.32-3) unstable; urgency=high
* Bug fix: "python-selinux: package almost empty (except on i386)",
thanks to Martin Dickopp. Actually, any time the sources are built
straight from the .dsc, there exists a possibility that that the swig
output .x file could be older than the source; and while it is
feasible to use "touch" and md5sums of source files to fix this, it is
far less kludgy to just build depend on swig. No other changes are
made, and the swig output is only used by the python-selinux package.
This fixes a grave bug on python-selinux (Closes: #395915).
-- Manoj Srivastava Sun, 5 Nov 2006 13:19:27 -0600
OK, dude, swig, is SO NOT A DEPENDENCY HERE. Which frees up
logrotate, cron, and I think from my notes sarge pam. But
building the debian package fails at the last step with this:
dpkg --build /home/mexon/courier/libselinux1-dev/libselinux-1.32/debian/python-selinux ..
dpkg-deb: parse error, in file `/home/mexon/courier/libselinux1-dev/libselinux-1.32/debian/python-selinux/DEBIAN/control' near line 6 package `python-selinux':
`Depends' field, reference to `python': error in version: version string is empty
make: *** [binary/python-selinux] Error 2
In debian/control, it's got this:
Package: python-selinux
Architecture: any
Depends: ${shlibs:Depends}, ${python:Depends}, python-support
Section: devel
Conflicts: python2.4-selinux (<= 1.30-1), libselinux-dev (<= 1.28-1)
Replaces: python2.4-selinux, libselinux-dev
Provides: ${python:Provides}
OK, so if I look on Aeon and see what that actually turns out
like, it's this:
Package: python-selinux
Priority: standard
Section: devel
Installed-Size: 240
Maintainer: Manoj Srivastava
Architecture: i386
Source: libselinux
Version: 1.32-3
Replaces: python2.4-selinux, libselinux-dev
Provides: python2.4-selinux
Depends: libc6 (>= 2.3.6-6), libselinux1 (>= 1.32), python (>= 2.4), python (<< 2.5), python-support
Conflicts: python2.4-selinux (<= 1.30-1), libselinux-dev (<= 1.28-1)
Filename: pool/main/libs/libselinux/python-selinux_1.32-3_i386.deb
So maybe if I just hardwire those versions, it'll all be OK?
Wait. I've got python-dev 2.5, and this is claiming 2.4. Well,
screw it. If there's anyone who actually wants python-selinux,
they're just going to have to hope that the difference isn't
significant. And yes, I have my debs. Great. Now logrotate is
going. But it wants cron before it'll install. Cron's going,
but I expect it'll refuse to install on scratchbox.
Unpacking cron (from cron_3.0pl1-100_armel.deb) ...
Setting up cron (3.0pl1-100) ...
addgroup: Only root may add a user or group to the system.
dpkg: error processing cron (--install):
subprocess post-installation script returned error exit status 255
Errors were encountered while processing:
cron
OK, how about this. I could install the package as root. To do
that, I need to sudo inside scratchbox. But that's not
possible:
[sbox-CHINOOK_ARMEL: ~/courier/cron] > sudo
sudo: must be setuid root
[sbox-CHINOOK_ARMEL: ~/courier/cron] > ls -l /usr/bin/sudo
-rwsr-xr-x 2 mexon mexon 85900 Aug 15 2007 /usr/bin/sudo
But outside scratchbox, I can change that to root.
aeon:/scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/bin# chown root.root sudo
aeon:/scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/bin# chmod a+s sudo
[sbox-CHINOOK_ARMEL: ~/courier/cron] > ls -l /usr/bin/sudo
-rwsr-sr-x 2 root root 85900 Aug 15 2007 /usr/bin/sudo
[sbox-CHINOOK_ARMEL: ~/courier/cron] > sudo sh
sudo: must be setuid root
Hmm. There's an FAQ.
In the meantime, I'll put sudo back the way I found it.
OK, how about this?
[sbox-CHINOOK_ARMEL: ~/courier/logrotate] > dpkg --install --force-depends logrotate_3.7.1-3_armel.deb
(Reading database ... 39403 files and directories currently installed.)
Preparing to replace logrotate 3.7.1-3 (using logrotate_3.7.1-3_armel.deb) ...
Unpacking replacement logrotate ...
dpkg: logrotate: dependency problems, but configuring anyway as you request:
logrotate depends on cron | anacron | fcron; however:
Package cron is not configured yet.
Package anacron is not installed.
Package fcron is not installed.
Setting up logrotate (3.7.1-3) ...
Right. Who wanted logrotate again? mgetty.
[sbox-CHINOOK_ARMEL: ~/courier/mgetty-fax] > dpkg --install mgetty-fax_1.1.35-3_armel.deb mgetty_1.1.35-3_armel.deb
Selecting previously deselected package mgetty-fax.
(Reading database ... 39382 files and directories currently installed.)
Unpacking mgetty-fax (from mgetty-fax_1.1.35-3_armel.deb) ...
Selecting previously deselected package mgetty.
Unpacking mgetty (from mgetty_1.1.35-3_armel.deb) ...
Setting up mgetty (1.1.35-3) ...
Setting up mgetty-fax (1.1.35-3) ...
/scratchbox/tools/bin/chown: changing ownership of `/var/spool/fax/outgoing/faxqueue_done': Operation not permitted
dpkg: error processing mgetty-fax (--install):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
mgetty-fax
Looking in the inst.sh:
if [ x"$chowncmd" != x ]; then $doit $chowncmd $dsttmp; fi
if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dsttmp; fi
if [ x"$stripcmd" != x ]; then $doit $stripcmd $dsttmp; fi
if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dsttmp; fi
Hmm, I thought that maybe making chmod not executable might
cause it to not bother. Wait, that's not testing for
executability, that's testing for existence. No, moving it away
didn't help.
OK, nothing for it. I'll compile a hacked up version which
doesn't try to do that, install it, then put it back and compile
it again so I don't accidentally distribute it.
Oh, wait, I must have been looking at the wrong file. It looks
completely different in there. Same strategy though. I'll
probably do something similar for sendmail. If it doesn't
actually run when required by some build, I can fix the
permissions as root myself. But this is mgetty-fax, remember,
and I need it to build courier. It's not very important that it
actually sends faxes. I hope.
Hmm. Unexpected results:
[sbox-CHINOOK_ARMEL: ~/courier/mgetty-fax] > dpkg --install mgetty-fax_1.1.35-3_armel.deb mgetty_1.1.35-3_armel.deb
(Reading database ... 39447 files and directories currently installed.)
Preparing to replace mgetty-fax 1.1.35-3 (using mgetty-fax_1.1.35-3_armel.deb) ...
Unpacking replacement mgetty-fax ...
Preparing to replace mgetty 1.1.35-3 (using mgetty_1.1.35-3_armel.deb) ...
Unpacking replacement mgetty ...
Setting up mgetty (1.1.35-3) ...
Setting up mgetty-fax (1.1.35-3) ...
failed to chown /usr/lib/mgetty-fax/faxq-helper: Operation not permitted
failed to chown /var/spool/fax/outgoing: Operation not permitted
failed to chown /var/log/mgetty/fax: Operation not permitted
failed to chown /var/run/mgetty-fax: Operation not permitted
failed to chown /var/lock/fax: Operation not permitted
And yet it's installed. Weird. So courier is now waiting on
netpbm libfam-dev courier-authlib-dev.
netpbm has no build deps. It's going. In the meantime,
libfam-dev. Also no build deps, and going. Except it fails:
checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables
See `config.log' for more details.
That's pretty weird. By the way, I'm running out of disk space.
courier-authlib fails like this:
dpkg-buildpackage: source package is courier-authlib
dpkg-buildpackage: source version is 0.58-4
dpkg-buildpackage: source changed by Stefan Hornburg (Racke)
dpkg-buildpackage: host architecture armel
dpkg-buildpackage: source version without epoch 0.58-4
: Using Scratchbox tools to satisfy builddeps
fakeroot debian/rules clean
dh_testdir
if [ `umask` != "0022" ]; then echo "You need to set umask to 022 in order to compile/build courier"; exit 1; fi
You need to set umask to 022 in order to compile/build courier
make: *** [check] Error 1
OK then, I just did that. And it's building.
Oh bugger:
Compiling gdbmobj3.c
Linking libgdbmobj.la
Compiling testgdbm.C
Linking testgdbm
/usr/lib/gcc/arm-none-linux-gnueabi/3.4.4/libstdc++.so: undefined reference to `_Unwind_GetDataRelBase@GCC_3.0'
/usr/lib/gcc/arm-none-linux-gnueabi/3.4.4/libstdc++.so: undefined reference to `_Unwind_GetTextRelBase@GCC_3.0'
collect2: ld returned 1 exit status
make[4]: *** [testgdbm] Error 1
make[4]: Leaving directory `/home/mexon/courier/courier-authlib-dev/courier-authlib-0.58/gdbmobj'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/mexon/courier/courier-authlib-dev/courier-authlib-0.58/gdbmobj'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/mexon/courier/courier-authlib-dev/courier-authlib-0.58'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/mexon/courier/courier-authlib-dev/courier-authlib-0.58'
make: *** [build] Error 2
Sure would be nice to get a fix for that.
While I dwell on that, I'll get a couple of dependencies
outstanding for emacs. libpng3-dev is apt-gettable. That
leaves mailx and xaw3dg-dev. Was mailx building before? Yes,
and it's on my server. It drags in xmail and sendmail-base, and
sendmail-base fails. But maybe I can force xmail to install
despite the missing dependency. Oh, xmail fails with the
GetDataRelBase error.
Now that's weird. I managed to compile it fine the other day.
That would suggest that I've broken my environment somehow. So
let's try moving my data out of the scratchbox, trashing the
whole of scratchbox, reinstalling, and trying again.
Holy crap, do you know I actually forgot to -u mexon with the
scratchbox install just now?
That's doing its thing, but I need some fresh air and some
sunshine.
Man, that's better.
So I'm compiling xmail. Successfully. So that purging seems to
have helped. Let's try that courier library.
This is showing me a bunch of stuff that failed to upload for
one reason or another. libldap and libgnutls11. Maybe because
the distribution is unstable? The cups libraries are missing
too, preventing my meisterwerk, gs, from being installed.
No, I think my core problem is libtasn1-2:
mat@alice:~$ reprepro -V -b /var/www/apt --ignore=wrongdistribution --ignore=missingfile include chinook libtasn1-2_0.2.10-3sarge1_armel.changes
WARNING: Distribution chinook contains an architecture called 'all'.
WARNING: Distribution chinook contains an architecture called 'all'.
WARNING: Distribution chinook contains an architecture called 'all'.
Data seems not to be signed trying to use directly...
.changes put in a distribution not listed within it!
Ignoring as --ignore=wrongdistribution given.
No priority specified for 'libtasn1-2_0.2.10-3sarge1_armel.changes'!
Exporting indices...
There have been errors!
Maybe because it's sarge? 1-2 is only available in
sarge. Similarly, libgnutls is only available as gnutls13 in
etch, not the 11 specified elsewhere. Maybe I should try and
stick to only etch. I'm recompiling a couple of things as etch.
So I guess this means that my repository only has etch in it.
Not sure how I feel about that.
I think there may be a problem. Etch openldap depends on
debconf-utils. debconf-utils depends on libqt-perl. And QT
depends on the world. So here, I think I have to dpkg --install
the other openldap. Those would be the ones you just deleted
Mat. Oops. Maybe I can force debconf to build regardless, and
its configure script will notice that I don't have QT.
libintl-perl failed like this.
dh_install -a --sourcedir=debian/tmp
cp: cannot stat `debian/tmp//usr/share/man/man3/Locale::gettext_xs.3pm': No such file or directory
dh_install: command returned error code 256
Luckily, not before it'd built the actual deb. But I'm in a
world of perl modules here. They'd better work. libyaml-perl
did. libmodule-build-perl completely failed though, with stuff
to do with XSTest.c. A sample:
t/pod_parser....ok
t/runthrough....ok
7/28 skipped: YAML.pm is not installed, or disabled
t/signature.....skipped
all skipped: Skipping unless $ENV{TEST_SIGNATURE} is true
t/versions......ok
t/xs............ok 2/12XSTest.xs:1:20: EXTERN.h: No such file or directory
XSTest.xs:2:18: perl.h: No such file or directory
XSTest.xs:3:18: XSUB.h: No such file or directory
XSTest.c:17: warning: parameter names (without types) in function declaration
XSTest.c:17: warning: data definition has no type or storage class
This is odd:
Feature 'YAML_support' disabled because of the following prerequisite failures:
* Version 0.62 of YAML is installed, but we need version < 0.49
I'm retreating to sarge. Life's too short. Note that openldap
uses the same source regardless. Oh. That's odd. The sarge
version depends on debconf-utils too. So I must have got that
from some repository or other.
Ah. I got it from bora. Lovely. So what did I install from
sarge? libtasn1-2-dev, and that's it. Right, so ldap fails
like this:
configure: error: could not locate libtool ltdl.h
make: *** [/home/mexon/courier/libldap2-dev/openldap2-2.1.30/debian/build/Makefile] Error 1
That was libtool-dev. Oh man, I wish I'd taken better notes.
Ah! Got it, libltdl3-dev, and I can apt-get it. From myself,
of course. So I'm going with openldap again. But watch it:
last time this failed. If I do have to go back to sarge in the
end I'll be unhappy.
openldap compiled. That makes me happy. So we're going with
this courier library. Last time it failed because of that
GetTextRelBase thing. Hopefully this time it will go better.
Another thing that failed was swig. Of course, swig depends on
the entire world of programming languages. But I might be able
to force it. It does need quilt though. Ah, screw it, swig was
a dead end anyway. More interesting was gengetopt. That was
for inetutils-inetd. Yep, that compiled. inetutils is going.
courier-authlib compiled. Getting very close now. Still have
lots of courier dependencies though. libfam-dev. Last time it
failed becuse C++ couldn't produce executables.
inetutils fails like this:
autoreconf -f -i
/usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal
aclocal: macro `gl_VISIBILITY' required but not defined
autoreconf2.50: aclocal failed with exit status: 1
make: *** [configure] Error 1
Let's concentrate on dependencies of courier for the moment.
Oh, no, wait, I've been using -d again. I hope I didn't mess
anything up.
libsepol1 is definitely in the archive now.
I'm on the verge of installing cron. I need adduser though,
from debfarm.free.fr. But cron fails because it can't add a
user or group, of course. I commented out all the group crontab
stuff in postinst. Hmm, I never installed libselinux1-dev. I
think I must have been doing cron with the -d flag before.
Do you think I should upload this cron? Possibly. After all,
it's easy enough to manually fix up once it's installed. No, I
think for safety I'll leave the paranoid one on the server.
Actually, that's essential if I was going to install on a real
device. And cron is there. Yay. What was I doing that for?
Probably for courier. Oh yes, logrotate, mgetty-fax.
mgetty-fax has its own problems. Same strategy I think: build
once straight, upload, then hack up and install locally.
Wow, weird dependency problems here. I can't install tetex-base
because it conflicts with osso somehow.
[sbox-CHINOOK_ARMEL: ~/courier/mgetty-fax/mgetty-1.1.35] > apt-get install tetex-base
...
The following packages have unmet dependencies:
texinfo: Conflicts: tetex-base (< 3.0) but 2.0.2c+maemo2-8osso3 is to be installed
Ah:
The following packages have unmet dependencies:
tetex-base: Depends: texinfo (>= 4.0b-1) but it is not going to be installed
Presumably I have to compile my own. Christ, tetex-base is
92.8MB of source. Maybe I got it from somewhere else? Ah, no,
it's texinfo I need.
I'm just over in emacs land, and the scary dependency was
xaw3dg. But it only depends on xutils-dev, and I've already got
that!
I think I might need tetex-bin. There must have been a reason
why I installed it last time. The remaining dependencies for
mgetty-fax are texi2html tetex-bin groff, and I'm very confused
by them.
OK, the only thing standing in the way of me compiling emacs is
this:
Setting up xmail (1.22-5) ...
/scratchbox/tools/bin/chown: changing ownership of `/var/spool/xmail/spool/local': Operation not permitted
So I comment out those lines. Remember that this is a hacked
version and shouldn't be uploaded.
Whoops! A little shaky on the dismount, but we made it!
Unpacking xmail (from xmail_1.22-5_armel-hacked.deb) ...
Setting up xmail (1.22-5) ...
failed to chown /var/lib/xmail/sendmail/xsendmail: Operation not permitted
E: XMail not started. Skipping configuration....
[sbox-CHINOOK_ARMEL: ~/emacs/xmail] > apt-get install mailx
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
mailx
0 upgraded, 1 newly installed, 0 to remove and 16 not upgraded.
Need to get 0B/155kB of archives.
After unpacking 295kB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
mailx
Install these packages without verification [y/N]? y
/scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such file or directory
Selecting previously deselected package mailx.
(Reading database ... 25954 files and directories currently installed.)
Unpacking mailx (from .../mailx_1%3a8.1.2-0.20050715cvs-1_armel.deb) ...
Setting up mailx (8.1.2-0.20050715cvs-1) ...
And emacs is going! Must remember not to screw with texinfo or
anything like that while it's going.
Right, problems. Etch tetex depends on libpoppler-dev, which
depends on libqt3-mt-dev. What do I do? Let's see what xorg is
doing nowadays. Note that I have to copy vars.arm to
vars.armel. Hmm, it seemed that last time it wanted gcc4, but
it seems to be working anyway here. It would make me enormously
happy if that would actually compile. No, those must have been
some kind of empty wrappers.
Ah, yes, here we go. mesa. And yes, it does indeed depend on
gcc4. There's a thing called gcc-defaults, and it depends on
gcj. So we won't be having that.
Emacs seems to be thrashing on this. Or it might have been an
earlier edeff-diff that I thought was thrashing. Check back at
5:00.
Ignoring risky spec in the local variables list
Loading ediff-init.el (source)...
Loading ange-ftp (source)...
Loading ediff-util.el (source)...
Loading ediff-help.el (source)...
Loading ediff-mult.el (source)...
Loading ediff-wind.el (source)...
Loading ediff-diff.el (source)...
Loading ediff-merg.el (source)...
Loading ediff.el (source)...
Loading dired...
Loading info (source)...
Loading ediff-ptch.el (source)...
About mgetty-fax. I think it needed tetex-bin so that it could
have dvips. So that's why I had my little hack. For
mgetty-fax, I can do that again. No, it's something else.
texi2dvi mgetty.texi
You don't have a working TeX binary installed, but the texi2dvi script
can't proceed without it. If you want to use this script, you have to
install some kind of TeX, for example teTeX Debian packages. You can do
that with this command:
apt-get install tetex-bin
make[2]: [mgetty.dvi] Error 1 (ignored)
In that case I'll get rid of my dodgy dvips.
Installation failed like this:
Setting up mgetty-fax (1.1.35-3) ...
/scratchbox/tools/bin/chown: changing ownership of `/var/spool/fax/outgoing/faxqueue_done': Operation not permitted
I needed to do a similar hack to last time. Rebuilding.
Meanwhile, emacs was definitely hung. Maybe I'll try 22. No,
that's a silly idea.
OK, mgetty-fax is installed. And off we go with courier. I
believe this is the first time I've tried compiling this
particular package. Should be interesting.
Well I am trying emacs22, and the only additional dependency
it's asking for is imagemagick. That's very kind.
Except that imagemagick depends on a whole pile of horrible
stuff, including specifically gs-gpl. But never fear! This is
definitely available under maemo. From mango.dia.unisa.it.
Holy crap, it's huge! And I had that on my n810 all this time!
I'm getting rid of that.
So as of right now, both emacs22 and courier are compiling.
Well, configurating. So this is good.
If I want an MTA that isn't going to give me headaches, I might
try msmtp. It just relays all email somewhere else. esmtp-run
does the same. Or masqmail, which is designed for hosts that
don't have a connection to the internet. And ssmtp pretty much
comes out best of all. In fact, the correct approach is
basically anything except what I've been trying to do.
ssmtp fails to install like this:
Setting up ssmtp (2.61-11.1) ...
hostname: unrecognized option `--fqdn'
BusyBox v1.6.1 (2007-09-27 18:08:59 EEST) multi-call binary
Usage: hostname [OPTION] {hostname | -F FILE}
dpkg: error processing ssmtp (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
ssmtp
E: Sub-process /usr/bin/dpkg returned an error code (1)
Fix that by removing the "qdn". And there you go. I have an
MTA.
So that's great. The next problem is update-inetd. The package
might be completely unnecessary. In fact I'm sure it is. So I
want to recompile netbase saying that it provides update-inetd.
And in order to that, I'm going to need to comment out, at least
temporarily, the etch sources.
Emacs 22 just zipped through this:
Loading dired...
Loading /home/mexon/emacs/emacs/emacs22-22.1+1/lisp/info.el (source)...
Loading /home/mexon/emacs/emacs/emacs22-22.1+1/lisp/ediff-ptch.el (source)...
Loading /home/mexon/emacs/emacs/emacs22-22.1+1/lisp/ediff-vers.el (source)...
So that's progress. Meanwhile, is courier stuck? No, it just
takes it a long time to figure out the maximum length of command
line arguments. OK, so I've put that on my server. How do I
get it to the n810? Probably with wget. Hmm, that didn't help.
Wait, it did help. I still have to install an inetd though.
Um. I seem to have a mail server running on my n810. No, no I
don't. Certainly when I typed that last sentence, because I
hadn't enabled it in the configuration. But I still can't
connect even if I do. No, it's really not running.
/home/user # /usr/sbin/dovecot
Warning: Corrected permissions for login directory /var/run/dovecot/login
/home/user # ps auxww | grep dovecot
15696 root 1888 RW grep dovecot
I think I need to strace it. Oh, there's a log:
dovecot: Feb 16 17:57:33 Info: Dovecot starting up
dovecot: Feb 16 17:57:34 Error: Auth process died too early - shutting down
dovecot: Feb 16 17:57:34 Error: child 15759 (auth) returned error 127
imap-login: Feb 16 17:57:34 Fatal: fd_send(-1) failed: No such file or directory
Ah, here in the strace:
writev(2, [{"dovecot-auth", 12}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"libpq.so.3", 10}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10)
= -1 EBADF (Bad file descriptor)
io_submit(0x7f, 0x7f, 0xa
Not sure if that's really a dependency. Let's see what it does
if I install that.
Same thing. It wants specifically libpq3. And that's not
installable. Wow. Weird.
I was going to recompile dovecot, since the last compile was
before the great wipe-cleaning. So let's do that. Remember how
I had postgresql installed in /usr/local? That'll surely be it.
Yes, yes yes yes, that makes sense, sarge is still on Postgresql
3. Of course, now I have the problem that I have to try and
compile postgresql. Wait, no I don't, postgresql-dev works
doesn't it?
Bunch of dependencies: libmysqlclient15-dev libkrb5-dev byacc.
Kerberos depends on comerr-dev. And this is feeling awfully
familiar.
Ha! Look what courier just did:
make[7]: Entering directory `/home/mexon/courier/courier/courier-0.53.3/courier/filters/perlfilter'
Compiling perlfilter.c
Linking perlfilter
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/bin/../lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../arm-none-linux-gnueabi/bin/ld: /scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a(DynaLoader.o): Relocations in generic ELF (EM: 3)
/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[7]: *** [perlfilter] Error 1
make[7]: Leaving directory `/home/mexon/courier/courier/courier-0.53.3/courier/filters/perlfilter'
make[6]: *** [all] Error 2
So the big question now is, do I trash my development
environment again? I have built quite a few libraries now.
Is emacs hung? Yes, it is. So it's all gone wrong. I think I
will need to reinstall my environment. And next time, I'll take
the packages one at a time. I think I may be overloading the
system somehow. Well, I tell you what, I'll try stopping it and
starting it (it has /etc/init.d/scratchboxsomething), then I'll
try rebuilding courier from scratch. And I won't do anything
else.
It may be snappier, but my god, it takes a long time to
configure itself.
Wait wait wait. That's not the GetDataRelBase error that caused
me to reinstall everything. That's the DynaLoader error.
There's a bug, from
September last year. Doesn't seem to have been fixed. So this
courier build is doomed, unless I can find some way to disable
the perl part.
I think my better approach is to try and concentrate on getting
dovecot working like I did last time. And since that one used
sarge, I'll do that again this time. Yes, the only unmet
dependency is postgres. And I'll get the postgres 5 sources and
install them locally. Wow, weird, I need to get that from etch
backports. I hope it works.
No, wait. If I just force the build, it will probably build
without any postgres support at all. That's what I want. It'll
probably pick up libmsql dependencies somehow.
It built. That was quick! What's more, it works. Except that
it doesn't: I can connect, but not login:
dovecot-auth: Feb 16 19:34:20 Info: PAM: pam_authenticate(mailtest) failed: Module is unknown
dovecot-auth: Feb 16 19:34:20 Info: PAM: pam_authenticate(mailtest) failed: Module is unknown
dovecot-auth: Feb 16 19:34:27 Info: PAM: pam_authenticate(mailtest) failed: Module is unknown
dovecot-auth: Feb 16 19:34:27 Info: PAM: pam_authenticate(mailtest) failed: Module is unknown
Googling around for just what the hell "PAM" is, it may be that
I need to install libsasl2-modules. I can even connect via TLS,
but I can't actually login.
I think I'll have a go at the dependencies of etch dovecot.
Primarily kerberos. Depends on comerr-dev in e2fsprogs.
Depends on a newer text2html. Which is now compiling. And
installed. I also need libdevmapper-dev. Fails like this:
gcc -c -Iioctl -I. -I../include -DHAVE_CONFIG_H -DDM_COMPAT -DDM_IOCTLS -DDEVICE_UID=0 -DDEVICE_GID=6 -DDEVICE_MODE=0660 -fPIC -Wall -Wundef -Wshadow -Wcast-align -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -O2 ioctl/libdm-iface.c -o ioctl/libdm-iface.o
In file included from ioctl/libdm-iface.c:22:
ioctl/libdm-compat.h:43: error: syntax error before "__kernel_dev_t"
ioctl/libdm-compat.h:43: warning: no semicolon at end of struct or union
ioctl/libdm-compat.h:48: error: syntax error before '}' token
ioctl/libdm-compat.h:63: error: syntax error before "__kernel_dev_t"
ioctl/libdm-compat.h:63: warning: no semicolon at end of struct or union
It's from linux-kernel-headers. What happens if I replace that
symbol with dev_t? It helps! I think the problem is that
configure is seeing my real kernel, but the headers belong to a
different one. Well, that's a theory, anyway. That appears to
have salvaged a very sticky situation. Hmm:
mat@alice:/var/www/apt/pool/main$ incoming-packages
WARNING: Distribution chinook contains an architecture called 'all'.
WARNING: Distribution chinook contains an architecture called 'all'.
WARNING: Distribution chinook contains an architecture called 'all'.
Data seems not to be signed trying to use directly...
Cannot put file 'dmsetup-udeb_1.02.08-1_armel.udeb' into component 'main', as it is not listed in UDebComponents!
Exporting indices...
There have been errors!
Maybe I can remove the udeb from the changes file? Yes, that
worked. e2fsprogs fails like this:
/home/mexon/courier/comerr-dev/e2fsprogs-1.39+1.40-WIP-2006.11.14+dfsg/lib/ext2fs/ext2fs.h:449:3: warning: #warning "Compression support is experimental"
CC /home/mexon/courier/comerr-dev/e2fsprogs-1.39+1.40-WIP-2006.11.14+dfsg/e2fsck/profile.c
CC prof_err.c
LD e2fsck.shared
CP e2fsck
LD e2fsck.static
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/bin/../lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../arm-none-linux-gnueabi/lib/libpthread.a(unwind.o): In function `unwind_stop': undefined reference to `_Unwind_GetCFA'
/scratchbox/compilers/cs2005q3.2-glibc2.5-arm/bin/../lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../arm-none-linux-gnueabi/lib/libpthread.a(unwind.o): In function `unwind_stop': undefined reference to `_Unwind_GetCFA'
Hmm. I can in fact install e2fsprogs, from debfarm.free.fr.
Maybe I can install sarge libkrb5-dev. Wow, it still wants
comerr-dev. How did I do this last time? I know, how about
forcing libkrb. It probably doesn't really need that. However,
it also wants ss-dev, so let's try that. No, that also comes
from e2fsprogs. No, it really wants it:
configure: error: cannot find add_error_table in com_err library
make: *** [configure-stamp] Error 1
Oh well, I guess I give up. Try to figure out what's wrong with
dovecot and PAM. A breakthrough!
open("/lib/security/pam_unix.so", O_RDONLY) = -1 ENOENT (No such file or directory)
Install libpam-modules.
I would just like to point out, right now, for the sake of those
in the audience, that I NOW HAVE A MAIL SERVER RUNNING ON MY
FUCKING PDA!
And I can actually connect to local host as well. But none of
the email clients actually want to talk to my mail server.
Modest refuses to accept "localhost" as a valid name. The
normal mail client refuses to connect unless there's a WLAN
connection. Aha! You can fool Modest into connecting to
nokia-n810-50-2. Must have localhost hard-coded somewhere. But
can I do it in offline mode? Do you know what, I think that
worked. Let me try it again. Exit modest. Connect. Put an
email in the folder. Go offline. Fire up modest. Yep! It
works! Exactly like I planned. Well. There's a turn up for
the books.
Let's have another go at Emacs.
No, no. The next step is to remove everything even remotely
email-related from my PDA, then try to make it so that you can
install dovecot-imapd and get whatever's necessary. I guess
it's acceptable if libpam-modules is also a requirement.
Or, I could go to bed. Wow. That's gotta be an option.
Well, I'll compromise and start the compile of emacs, but ignore
it. And I'll have a cup of tea. By the way, what's up with
clisp?
Well, clisp needs libsigsegv. The Etch version seems to need
gcc-4.1.
OK, I want to upload libsigsegv, and it's the usual sarge drama.
But I notice that I actually have libsigsegv-dev 2.4 already
there, somehow. How did that happen? So it occurs to me to try
forcing the build, and see what breaks. Well, I don't need to:
this
breaks. Or it might not. Why not try it and see?
Emacs 21 just made it through the ediff-ptch.el thing that was
"hung" before. I think it's just absurdly slow.
libsigsegv successfully build. Well how about that.
Emacs appears to have only made it through a couple of lines of
build in half an hour. I'll leave it overnight, but here's the
status now:
Warning: arch-independent data dir (/usr/share/emacs/21.4/etc/) does not exist.
Ignoring risky spec in the local variables list
Loading ediff-init.el (source)...
Loading ange-ftp (source)...
Loading ediff-util.el (source)...
Loading ediff-help.el (source)...
Loading ediff-mult.el (source)...
Loading ediff-wind.el (source)...
Loading ediff-diff.el (source)...
Loading ediff-merg.el (source)...
Loading ediff.el (source)...
Loading dired...
Loading info (source)...
Loading ediff-ptch.el (source)...
Loading ediff-vers.el (source)...
Loading vc (source)...
Just looking through some of my failures. It'd be worth taking
another look at lynx. That one really bugged me. A few of the
others can probably be installed by ignoring their qt
dependencies and trusting in the configure script to sort it
out. Actually, aptitude can probably be done that way.
But in the meantime, I'm building lisp. I get what the guy was
talking about now. Just because configure fails, doesn't mean
you can't make, especially when it tells you to:
/bin/sh ./libtool --mode=compile gcc -x none -c vacall-arm.s
gcc -x none -c vacall-arm.s -o vacall-arm.o
vacall-arm.s: Assembler messages:
vacall-arm.s:3: Warning: ignoring attempt to redefine built-in register 'sl'
vacall-arm.s:3: Warning: ignoring attempt to redefine built-in register 'SL'
vacall-arm.s:4: Warning: ignoring attempt to redefine built-in register 'fp'
vacall-arm.s:4: Warning: ignoring attempt to redefine built-in register 'FP'
vacall-arm.s:5: Warning: ignoring attempt to redefine built-in register 'ip'
vacall-arm.s:5: Warning: ignoring attempt to redefine built-in register 'IP'
vacall-arm.s:6: Warning: ignoring attempt to redefine built-in register 'sp'
vacall-arm.s:6: Warning: ignoring attempt to redefine built-in register 'SP'
vacall-arm.s:7: Warning: ignoring attempt to redefine built-in register 'lr'
vacall-arm.s:7: Warning: ignoring attempt to redefine built-in register 'LR'
vacall-arm.s:8: Warning: ignoring attempt to redefine built-in register 'pc'
vacall-arm.s:8: Warning: ignoring attempt to redefine built-in register 'PC'
vacall-arm.s:77: Error: selected processor does not support `ldfeqs f0,[sp,#20]'
vacall-arm.s:81: Error: selected processor does not support `ldfeqd f0,[sp,#20]'
make[1]: *** [vacall-arm.lo] Error 1
make[1]: Leaving directory `/home/mexon/clisp/clisp/clisp-2.41/src/callback/vacall_r'
make: *** [all-subdirs] Error 2
Configure findings:
FFI: no (user requested: default)
readline: yes (user requested: default)
libsigsegv: yes
To continue building CLISP, the following commands are recommended
(cf. unix/INSTALL step 4):
cd src
./makemake > Makefile
make config.lisp
vi config.lisp
make
make check
So when I wake up tomorrow, I may well have a working clisp of
sorts to greet me.
It's tomorrow, and Emacs was maxing out my CPU but hadn't got
one line further. So that was definitely hung in an infinite
loop. Not good. Meanwhile, clisp got to here:
installing es.gmo as ../locale/es/LC_MESSAGES/clisp.mo
installing clisplow_es.gmo as ../locale/es/LC_MESSAGES/clisplow.mo
installing nl.gmo as ../locale/nl/LC_MESSAGES/clisp.mo
installing clisplow_nl.gmo as ../locale/nl/LC_MESSAGES/clisplow.mo
installing ru.gmo as ../locale/ru/LC_MESSAGES/clisp.mo
installing clisplow_ru.gmo as ../locale/ru/LC_MESSAGES/clisplow.mo
make[1]: Leaving directory `/home/mexon/clisp/clisp/clisp-2.41/src/po'
rm -rf data
mkdir data
cd data && ln -s ../../utils/unicode/UnicodeDataFull.txt .
cd data && ln -s ../../doc/Symbol-Table.text .
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -DUNICODE -I. -x none spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o unixaux.o built.o ariarm.o modules.o libcharset.a -lreadline -lncurses -ldl -lsigsegv -o lisp.run
./lisp.run -B . -N locale -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW -x "(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)"qemu: uncaught target signal 4 (Illegal instruction) - exiting
make: *** [interpreted.mem] Error 252
That's not enough to be useful. For some reason I was building
in the Debian patched version, but I doubt it makes a
difference. I could try the latest tarball though.
I'm also fiddling about seeing if lynx will install now. Its
only unmet build dependency is libncursesw5, which now appears
to be installable.
The configure script for clisp-2.44 runs through OK, although it
claims that it won't be compiling FFI. It also says this:
# The default stack size on your platform is insufficient
# and must be increased to at least 16384. You must do either
# 'ulimit -s 16384' (for Bourne shell derivatives, e.g., bash and zsh)
# or 'limit stacksize 16384' (for C shell derivarives, e.g., tcsh)
So I did that. Let's see what builds. Meanwhile, lynx built
successfully. That was wanted by xfree86, but I won't try that
for the moment. Odd, the version number for Etch lynx is still
"2.8.5-2sarge2.2". Guess no-one's needed to patch it for a
while.
Clisp 2.44 doesn't get as far as 2.41:
ariarm.s:1343: Error: bad instruction `replaced by multiplication of a small x=a1 and a big y=ip:*/'
make: *** [ariarm.o] Error 1
Oh, come on, who's responsible for this? If you're going to
comment out code (and you shouldn't), use #if 0, not comments:
/* BL mulu32_64_vregs /* muluD(digit,*--ptr,hi=,lo=) */
replaced by multiplication of a small x = a1 and a big y = ip : */
--- ariarm.c~ 2008-02-17 07:46:35.000000000 +0100
+++ ariarm.c 2008-02-17 07:53:19.000000000 +0100
@@ -1835,8 +1835,10 @@
LABEL(mulusmall_loop_down_l1)
LDR ip,[a2,#-4]!
-/* BL mulu32_64_vregs /* muluD(digit,*--ptr,hi=,lo=) */
- replaced by multiplication of a small x = a1 and a big y = ip : */
+#if 0
+ BL mulu32_64_vregs /* muluD(digit,*--ptr,hi=,lo=) */
+ replaced by multiplication of a small x = a1 and a big y = ip :
+#endif
MOV v1,ip,LSR #16 /* top half of y */
BIC ip,ip,v1,LSL #16 /* bottom half of y */
MUL v2,a1,v1 /* middle section of result */
Let's try again, shall we? Now it fails like this:
cd data && ln -s ../../doc/Symbol-Table.text .
gcc -g -O2 -Igllib -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -DUNICODE -I. -x none spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o unixaux.o built.o ariarm.o gllib/uniwidth/width.o gllib/uniname/uniname.o gllib/localcharset.o modules.o -lreadline -lncurses -ldl -lsigsegv -o lisp.run
./lisp.run -B . -N locale -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 2MW -x "(and (setq custom::*load-paths* (quote (\"\"))) (load \"init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)"
qemu: uncaught target signal 11 (Segmentation fault) - exiting
make: *** [interpreted.mem] Error 245
Exactly the same point as before. I guess I could try debugging
it. Do I even have gdb? No, but it's installable.
Over at aptitude... Dependencies libapt-pkg-dev (>= 0.6.0)
libsigc++-2.0-dev libcppunit-dev po4a. The first of those is
apt.
Man, I was way confused by the weird way gdb was behaving, but
it turns out there's a .gdbinit included in the source
distribution. OK, I guess, but gdb gives me the shits at the
best of times, I hope no-one's made it behave even more
incomprehensibly.
Oh, I haven't set NO_GENERATIONAL_GC yet, have I? Let's try that.
Note that the
guy installing clisp on the n800 was using 2.41.
apt is done. Now libsigc++-2.0-dev.
NO_GENERATIONAL_GC didn't help at all:
gcc -DNO_GENERATIONAL_GC -Igllib -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -DUNICODE -I. -x none spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o unixaux.o built.o ariarm.o gllib/uniwidth/width.o gllib/uniname/uniname.o gllib/localcharset.o modules.o -lreadline -lncurses -ldl -lsigsegv -o lisp.run
./lisp.run -B . -N locale -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 2MW -x "(and (setq custom::*load-paths* (quote (\"\"))) (load \"init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)"
qemu: uncaught target signal 11 (Segmentation fault) - exiting
make: *** [interpreted.mem] Error 245
I think I'll give up for a bit. There's some perl modules I'll
be needing for my ical generator, I'll do those. Note that I
have dependencies on libtimedate-perl, libdata-ical-perl and
libdata-ical-timezone-perl. Neither of those last two are in
Debian yet. Hmm.
libsigc++ is done. Next is cppunit-1.12.0. And this is the
part that depends on QT. And doxygen, which is apt-gettable.
But QT isn't. I'm going to try forcing this to compile and hope
that configure does its job.
I guess I'm going to have to package up these perl modules
myself. This
article talks about how. Except that dh-make-perl isn't
available. So let's build that.
libcppunit-dev failed like this:
make[2]: Leaving directory `/home/mexon/aptitude/libcppunit-dev/cppunit-1.12.0/doc'
make[2]: Entering directory `/home/mexon/aptitude/libcppunit-dev/cppunit-1.12.0'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/home/mexon/aptitude/libcppunit-dev/cppunit-1.12.0'
make[1]: Leaving directory `/home/mexon/aptitude/libcppunit-dev/cppunit-1.12.0'
cd src/qttestrunner && qmake-qt3 qttestrunnerlib.pro
/scratchbox/tools/bin/sh: line 1: qmake-qt3: command not found
make: *** [build-stamp] Error 127
So I'm going to have to badly hack this up, and it won't be
suitable for uploading. Man, I have no idea which of Makefile,
Makefile.am and Makefile.in is the real input file. I'll edit
the last two. And the rules file has a bunch of qt stuff too.
To install dh-make-perl I need libmodule-depends-perl. Which
was easy enough. But that needs libfile-chdir-perl and
libclass-accessor-chained-perl. This is going to get ugly.
Well libfile-chdir-perl installed OK. But
libclass-accessor-chained-perl requires libclass-accessor-perl.
libcppunit-dev failed like this:
# Runtime library package
dh_install -plibcppunit-1.12-0 --autodest debian/tmp/usr/lib/lib*.so.*
# Qt Test runner library package
#dh_install -plibqttestrunner1c2a lib/lib*.so.* usr/lib
# Developer package
dh_install -plibcppunit-dev --autodest debian/tmp/usr/bin/DllPlugInTester
dh_install -plibcppunit-dev --autodest debian/tmp/usr/bin/cppunit-config
dh_install -plibcppunit-dev --autodest debian/tmp/usr/lib/lib*.so
dh_install -plibcppunit-dev lib/lib*.so usr/lib
dh_install: libcppunit-dev missing files (lib/lib*.so), aborting
make: *** [install] Error 1
At least dh-make-perl installed. And it fails like this:
[sbox-CHINOOK_ARMEL: ~/ical/libdata-ical-perl] > dh-make-perl Data-ICal-0.13
Package `perl' is not available.
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
Use of uninitialized value in concatenation (.) or string at /usr/bin/dh-make-perl line 147.
cat: /etc/mailname: No such file or directory
Error in option spec: "exclude|i:s{,}"
The obvious doesn't help:
[sbox-CHINOOK_ARMEL: ~/ical/libdata-ical-perl] > echo sbox > /etc/mailname
[sbox-CHINOOK_ARMEL: ~/ical/libdata-ical-perl] > dh-make-perl Data-ICal-0.13
Package `perl' is not available.
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
Use of uninitialized value in concatenation (.) or string at /usr/bin/dh-make-perl line 147.
Error in option spec: "exclude|i:s{,}"
The problem is this:
[sbox-CHINOOK_ARMEL: ~/ical/libdata-ical-perl] > dpkg -p perl
Package `perl' is not available.
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
In fact, perl isn't available in /var/lib/dpkg/available, even
though it's installed. I guess that's because it's part of
scratchbox. However, it is in /var/lib/apt/lists. Maybe I can
just copy one to the other. I'll add a Source line and remove
the Filename and MD5sum lines though. OK, dpkg -p perl now
seems happy. So now:
[sbox-CHINOOK_ARMEL: /var/lib/apt/lists] > dh-make-perl Data-ICal-0.13
Error in option spec: "exclude|i:s{,}"
I think I'm going to install libcppunit locally I'm afraid.
2010-04-06
Update from Nito:
dh-make-perl: I got this one working editing /usr/bin/dh-make-perl line 130 substituting:
'exclude|i:s{,}'
with
'exclude|i=s'
I'm guessing that the Getopt problems above are due to using an
older version of Getopt::Long than Etch really wants. I can try
retreating to Sarge.
I still need po4a for aptitude. That needs
libmodule-build-perl. Which fails:
XSTest.c:38: warning: parameter names (without types) in function declaration
XSTest.c:38: warning: data definition has no type or storage class
XSTest.c:40: error: redefinition of 'XS'
XSTest.c:19: error: previous definition of 'XS' was here
XSTest.c: In function `XS':
XSTest.c:41: error: `dXSARGS' undeclared (first use in this function)
XSTest.c:44: error: `XS_VERSION_BOOTCHECK' undeclared (first use in this function)
XSTest.c:46: error: `XS_XSTest_is_even' undeclared (first use in this function)
XSTest.c:47: error: `XSRETURN_YES' undeclared (first use in this function)
# Test 10 got: 'error building .o file from 'lib/XSTest.c' at /home/mexon/aptitude/libmodule-build-perl/libmodule-build-perl-0.26/blib/lib/Module/Build/Base.pm line 2455.
' (t/xs.t at line 78)
# Expected: ''
# t/xs.t line 78 is: ok $@, '';
t/xs............FAILED tests 3, 7, 10
Failed 3/12 tests, 75.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/xs.t 12 3 25.00% 3 7 10
1 test and 7 subtests skipped.
Failed 1/12 test scripts, 91.67% okay. 3/224 subtests failed, 98.66% okay.
make: *** [install] Error 255
[sbox-CHINOOK_ARMEL: ~/ical/libdata-ical-perl] > dh-make-perl Data-ICal-0.13
Found: Data-ICal 0.13 (libdata-ical-perl arch=all)
Use of uninitialized value in substitution (s///) at /usr/bin/dh-make-perl line 441.
Use of uninitialized value in substitution (s///) at /usr/bin/dh-make-perl line 442.
Use of uninitialized value in substitution (s///) at /usr/bin/dh-make-perl line 443.
Use of uninitialized value in substitution (s///) at /usr/bin/dh-make-perl line 444.
Use of uninitialized value in substitution (s///) at /usr/bin/dh-make-perl line 444.
Using maintainer: mexon
Found changelog: Changes
Found docs: README lib/Data/ICal/Entry/Todo.pm
Using rules: /usr/share/dh-make-perl/rules.MakeMaker.noxs
Done
To make debuild happy, unpack the tarball again into
Data-ICal-0.13.orig. But it gets into an infinite loop of
asking which continet I live on. So I'm going to try going to
the etch version again, but I'm going to hack up the script to
take out the offending option. What does "exclude|i:s{,}" mean
anyway? OK, after reading the documentation, I think omitting
the braces is probably the closest approximation to what is
intended. I'm not going to be using it anyway, and I guess few
people will.
I think my problem is that CPAN should be initialised before I
start. I can do that.
Meanwhile, po4a is more documentation wank. People's insistence
on building gigantic ziggurats of infrastructure to hold up
their pathetic little scrawlings is causing me no end of
trouble.
Before Ical will be happy, it'll need Test/LongString.pm. That
comes from libtest-longstring-perl. That requires
libtest-pod-perl libtest-pod-coverage-perl. The former requires
libio-stringy-perl libpod-simple-perl. Notice that
libpod-simple-perl is part of the nexus of documentation wank.
Man, these perl modules are going to make me unhappy. I need
libpod-escapes-perl perl-doc. At least perl-doc is
apt-gettable. Oh, from me. Well there you go. Sooner or later
some of these unit tests are going to fail and make me unhappy.
Well, libtest-pod-perl failed because it needs
Test/Builder/Tester.pm. That's from libtest-simple-perl. Hmm,
on Aeon I appear to have both the one from perl-modules and the
one from libtest-simple-perl installed. Let's try to replicate
that. All the way back to libtest-pod-coverage-perl, which now
requires libpod-coverage-perl. That requires
libdevel-symdump-perl libmodule-build-perl. Oops, and that last
one fails, remember?
So maybe I can fix that. Here's how it starts:
t/xs............ok 2/12XSTest.xs:1:20: EXTERN.h: No such file or directory
XSTest.xs:2:18: perl.h: No such file or directory
XSTest.xs:3:18: XSUB.h: No such file or directory
XSTest.c:17: warning: parameter names (without types) in function declaration
XSTest.c:17: warning: data definition has no type or storage class
XSTest.c: In function `XS':
XSTest.c:20: error: `dXSARGS' undeclared (first use in this function)
XSTest.c:20: error: (Each undeclared identifier is reported only once
XSTest.c:20: error: for each function it appears in.)
XSTest.c:21: error: `items' undeclared (first use in this function)
XSTest.c:22: error: `aTHX_' undeclared (first use in this function)
XSTest.c:22: error: syntax error before string constant
XSTest.c:26: error: `dXSTARG' undeclared (first use in this function)
In scratchbox, that's /usr/lib/perl/5.8.3/CORE/EXTERN.h. On
Aeon, it's /usr/lib/perl/5.8.8/CORE/EXTERN.h. Maybe that's the
problem. Note that this could also be related to my DynaLoader
problems, in which case I'm screwed. From the documentation to
Module::Build:
include_dirs
Specifies any additional directories in which to search for C
header files. May be given as a string indicating a single
directory, or as a list reference indicating multiple
directories.
So let's try adding a directory to Build.PL:
my $build = new Module::Build
(
module_name => 'XSTest',
include_dirs => [ File::Spec->curdir, "/usr/lib/perl/5.8.8/CORE" ],
);
No, that doesn't help. Is it possible to assume that this is
only unit tests, that the XS stuff will probably never be used,
and therefore I can just hack this module to skip the tests?
Probably. Also, it will probably work fine if I compile this on
the n810. Maybe I should do that instead. It'll mean
installing a pile of stuff, including gcc. No, that fails like
this:
dpkg-buildpackage: source package is libmodule-build-perl
dpkg-buildpackage: source version is 0.26-1
dpkg-buildpackage: source changed by Jay Bonci
dpkg-buildpackage: host architecture armel
dpkg-buildpackage: source version without epoch 0.26-1
fakeroot debian/rules clean
dh_testdir
Segmentation fault
sh: bad signal name 's'
So I hack the module to skip the tests. I guess what that means
is that XS really is broken, but not because
libmodule-build-perl itself is broken! So that package is fine,
and if some kind soul fixes the XS problems, the rest will fall
into place.
I still have some dependencies before I can install it:
libarchive-tar-perl and libextutils-parsexs-perl. The first
went well, the second depends on libextutils-cbuilder-perl. And
guess what, that last one depends on libmodule-build-perl.
Aha! But since all these perl modules are in section "all", I
can just copy over the ones from Aeon! That works fine for
libextutils-cbuilder-perl. I'll probably limit the amount I do
this though, since I'll probably want all of this stuff
available through my archive. And it's nice to test stuff to
see what works and how much hacking is necessary. For example,
libextutils-parsexs-perl also fails due to XS problems. I can
probably assume that libmodule-build-perl will fail to work,
even if I manage to get it installed.
Wait, had I already actually done libmodule-build-perl? I'm
confused. Anyway. To install libarchive-tar-perl I need
libio-zlib-perl. And that needs libcompress-zlib-perl. I
realise it's not as bad as you might think. The XS problems
only come in when it's trying to build the package: from then
on, it should be able to just load the shared libraries it
needs. Now, libcompress-zlib-perl fails:
t/06gzdopen.....Can't load '/home/mexon/aptitude/libcompress-zlib-perl/libcompress-zlib-perl-1.42/blib/arch/auto/Compress/Zlib/Zlib.so' for module Compress::Zlib: /home/mexon/aptitude/libcompress-zlib-perl/libcompress-zlib-perl-1.42/blib/arch/auto/Compress/Zlib/Zlib.so: cannot open shared object file: No such file or directory at /scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/DynaLoader.pm line 230.
at t/06gzdopen.t line 6
Compilation failed in require at t/06gzdopen.t line 6.
So it is that bad. But I think I can avoid all this pain by
jumping up to the top of the chain and seeing what can be
installed directly because it's in the all architecture. Let's
start with aptitude. No, that doesn't work. Ultimately, I need
libcompress-zlib-perl, and that's architecture-specific.
Oh, there's an
IRC log.
[sbox-CHINOOK_ARMEL: ~] > export PERL5LIB=/scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/lib/perl5:$PERL5LIB
No, that doesn't help. I even wondered if DynaLoader is somehow
running outside of scratchbox and couldn't find the file for
that reason, but putting a link in the correct location so the
file is there even outside scratchbox doesn't help either.
Using strace, I can see that it's /scratchbox/tools/bin/perl.bin
that can't see the library. Here's something
that might be helpful if I spoke Chinese. But that gets me here,
which looks far more useful. But I still don't get it.
Actually, those instructions probably apply to my problems with
eperl more than anything else.
I think what that file is telling me is that I need to compile
and install DynaLoader.a. That's presumably part of the core
perl package. It's in perl-base. In the scratchbox, there's no
DynaLoader.a installed. Nor is there on the n810.
OK, interesting. If I perldoc DynaLoader, ultimately it reads
this:
output:stat64("/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/DynaLoader.pm", {st_mode=S_IFREG|0444, st_size=28124, ...}) = 0
But I also have a native one in
/usr/lib/perl/5.8.3/DynaLoader.pm. If I use the PERL5LIB line
from earlier, it tries and fails:
output:stat64("./DynaLoader.pm", 0x814b158) = -1 ENOENT (No such file or directory)
output:stat64("/scratchbox/devkits/perl/lib/perl/DynaLoader.pm", 0x814b158) = -1 ENOENT (No such file or directory)
output:stat64("/scratchbox/devkits/debian-etch/lib/perl/DynaLoader.pm", 0x814b158) = -1 ENOENT (No such file or directory)
output:stat64("/scratchbox/devkits/debian-etch/lib/perl5/DynaLoader.pm", 0x814b158) = -1 ENOENT (No such file or directory)
output:stat64("/scratchbox/devkits/debian-etch/share/perl5/DynaLoader.pm", 0x814b158) = -1 ENOENT (No such file or directory)
output:stat64("/scratchbox/devkits/maemo3-tools/lib/perl5/DynaLoader.pm", 0x814b158) = -1 ENOENT (No such file or directory)
output:stat64("/scratchbox/devkits/maemo3-tools/share/perl5/DynaLoader.pm", 0x814b158) = -1 ENOENT (No such file or directory)
output:stat64("/scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/lib/perl5/DynaLoader.pm", 0x814b158) = -1 ENOENT (No such file or directory)
output:stat64("/scratchbox/devkits/maemo3-tools/lib/perl5/site_perl/5.8.4/i686-linux-thread-multi/DynaLoader.pm", 0x814b158) = -1 ENOENT (No such file or directory)
output:stat64("/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/DynaLoader.pm", {st_mode=S_IFREG|0444, st_size=28124, ...}) = 0
output:open("/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/DynaLoader.pm", O_RDONLY|O_LARGEFILE) = 3
OK, narrowing in on a solution here. Check this out:
[sbox-CHINOOK_ARMEL: ~/aptitude/libcompress-zlib-perl/libcompress-zlib-perl-1.42] > ls /usr/lib/perl/5.8.3
B Cwd.pm Encode.pm I18N O.pm SDBM_File.pm Unicode attrs.pm gnu signal.ph syslog.ph
B.pm Data Errno.pm IO ODBM_File.pm Safe.pm XS auto lib.pm stdarg.ph threads
ByteLoader.pm Devel Fcntl.pm IO.pm Opcode.pm Socket.pm XSLoader.pm bits limits.ph stddef.ph threads.pm
CORE Digest File IPC POSIX.pm Storable.pm _h2ph_pre.ph encoding.pm linux sys time.ph
Config.pm DynaLoader.pm Filter MIME POSIX.pod Sys asm endian.ph ops.pm syscall.ph wait.ph
Config.pod Encode GDBM_File.pm NDBM_File.pm PerlIO Time asm-generic features.ph re.pm syslimits.ph xlocale.ph
[sbox-CHINOOK_ARMEL: ~/aptitude/libcompress-zlib-perl/libcompress-zlib-perl-1.42] > ls /usr/lib/perl5
HTML Locale XML auto
The confusion is that I appear to have two versions of perl
installed. perl-base is 5.8.3. Ah, but perl is 5.8.4, because
it's on my native system! That explains it! "export
PERL5LIB=/usr/lib/perl/5.8.3". So I tried this:
[sbox-CHINOOK_ARMEL: ~/aptitude/libcompress-zlib-perl/libcompress-zlib-perl-1.42] > export PERL5LIB=/scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/lib/perl/5.8.3:$PERL5LIB
[sbox-CHINOOK_ARMEL: ~/aptitude/libcompress-zlib-perl/libcompress-zlib-perl-1.42] > strace -o output -ff dpkg-buildpackage -rfakeroot -uc -b Can't load '/scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/lib/perl/5.8.3/auto/POSIX/POSIX.so' for module POSIX: /scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/lib/perl/5.8.3/auto/POSIX/POSIX.so: cannot open shared object file: No such file or directory at /scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/lib/perl/5.8.3/XSLoader.pm line 68.
at /scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/lib/perl/5.8.3/POSIX.pm line 26
Compilation failed in require at /scratchbox/devkits/debian-etch/bin/dpkg-parsechangelog line 11.
BEGIN failed--compilation aborted at /scratchbox/devkits/debian-etch/bin/dpkg-parsechangelog line 11.
dpkg-buildpackage: unable to determine source package is
I think I need to combine the two directories somehow.
As an aside, I've realised that if these packages are in all, I
might be able to point to the main debian servers and get my
perl modules from them. Hmm, no, that doesn't seem to work. Pity.
Luckily, there doesn't seem to be any overlap. Hmm. On Aeon,
there is both perl5 and perl5.8.8, and there's considerable
overlap. Ah! I see. I can just do this:
[sbox-CHINOOK_ARMEL: ~] > ln -s /usr/lib/perl/5.8.3 /usr/lib/perl/5.8.4
[sbox-CHINOOK_ARMEL: ~] > ln -s /usr/share/perl/5.8.3 /usr/share/perl/5.8.4
OK, why was I stracing dpkg-buildpackage there? I really got
confused somewhere.
[sbox-CHINOOK_ARMEL: ~/aptitude/libcompress-zlib-perl/libcompress-zlib-perl-1.42] > export PERL5LIB=/scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/lib/perl/5.8.3:$PERL5LIB
[sbox-CHINOOK_ARMEL: ~/aptitude/libcompress-zlib-perl/libcompress-zlib-perl-1.42] > strace -o output perldoc DynaLoader Perl lib version (v5.8.3) doesn't match executable version (v5.8.4) at /scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/lib/perl/5.8.3/Config.pm line 32.
Compilation failed in require at /scratchbox/tools/lib/perl5/5.8.4/Pod/Perldoc.pm line 7.
BEGIN failed--compilation aborted at /scratchbox/tools/lib/perl5/5.8.4/Pod/Perldoc.pm line 7.
Compilation failed in require at /scratchbox/tools/bin/perldoc line 9.
BEGIN failed--compilation aborted at /scratchbox/tools/bin/perldoc line 9.
So let's try 5.8.4 instead:
[sbox-CHINOOK_ARMEL: ~/aptitude/libcompress-zlib-perl/libcompress-zlib-perl-1.42] > export PERL5LIB=/scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/lib/perl/5.8.4:/scratchbox/devkits/maemo3-tools/lib/perl5/site_perl/5.8.4/i686-linux-thread-multi
[sbox-CHINOOK_ARMEL: ~/aptitude/libcompress-zlib-perl/libcompress-zlib-perl-1.42] > strace -o output perldoc DynaLoader Perl lib version (v5.8.3) doesn't match executable version (v5.8.4) at /scratchbox/users/mexon/targets/CHINOOK_ARMEL/usr/lib/perl/5.8.4/Config.pm line 32.
Compilation failed in require at /scratchbox/tools/lib/perl5/5.8.4/Pod/Perldoc.pm line 7.
BEGIN failed--compilation aborted at /scratchbox/tools/lib/perl5/5.8.4/Pod/Perldoc.pm line 7.
Compilation failed in require at /scratchbox/tools/bin/perldoc line 9.
BEGIN failed--compilation aborted at /scratchbox/tools/bin/perldoc line 9.
Where does 5.8.4 come from anyway? The real version should be
5.8.3. Etch is on 5.8.8. Sarge is on 5.8.4, maybe it's that
somehow.
OK, I'm even more confused. dpkg claims that perl 5.8.3-3osso7
is installed. But in /usr/bin/perl, there's an executable which
claims that it's 5.8.4.
Dare I remove perl and try reinstalling it?
The following packages will be REMOVED:
autoconf automake1.8 automake1.9 build-essential debhelper
dh-make-perl docbook docbook-dsssl docbook-to-man docbook-xml
docbook-xsl dpkg-dev gnome-common gtk-doc-tools
hildon-application-framework-dev intltool intltool-debian jade
libclass-accessor-chained-perl libclass-accessor-perl
libextutils-cbuilder-perl libextutils-parsexs-perl
libfile-chdir-perl libhtml-parser-perl libhtml-tagset-perl
libhtml-tree-perl libintl-perl libio-stringy-perl
libmodule-depends-perl libperl-dev libpod-escapes-perl
libpod-simple-perl libtest-pod-perl libtest-simple-perl
libtimedate-perl liburi-perl libwww-perl libxml-parser-perl
libyaml-perl maemo-launcher-dev mgetty-fax perl perl-doc
perl-modules po-debconf sgml-base sgml-data xml-core
repository.maemo.org has chosen this moment to go down. Thanks
guys.
Note that this is the same problem preventing me from building
courier.
I'm just trying reinstalling dovecot, to check that it works.
Note that fuse causes trouble:
Removing fuse-utils ...
Purging configuration files for fuse-utils ...
Can't locate dpkg-gettext.pl in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.3 /usr/local/share/perl/5.8.3 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . /usr/lib/dpkg) at /usr/sbin/dpkg-statoverride line 13.
removing fuse device...
The group `fuse' is not a system group... Exiting.
The amazing thing is that after all that effort, all I have is
dovecot-common dovecot-imapd openbsd-inetd. It didn't even
worry about having an MTA, after all that. Ah, OK, that was
just emacs.
I managed to retrieve perl and perl-modules from the n810's apt
cache.
Aha!
[sbox-CHINOOK_ARMEL: ~] > /usr/bin/perl -v
This is perl, v5.8.4 built for i686-linux-thread-multi
...
[sbox-CHINOOK_ARMEL: ~] > cp /usr/bin/perl .
[sbox-CHINOOK_ARMEL: ~] > ./perl -v
This is perl, v5.8.3 built for arm-linux-gnueabi-thread-multi
...
So scratchbox is fooling with the filesystem somehow, making
/usr/bin/perl be something other than what it is. Oh, and I
just discovered this:
[sbox-CHINOOK_ARMEL: /usr/bin] > perl5.8.3 -v
This is perl, v5.8.3 built for arm-linux-gnueabi-thread-multi
So that's the solution. There's probably an environment
variable I can use, but instead I just hacked the control file
to force perl to perl5.8.3. And it works. No! No that doesn't
work:
The following packages have unmet dependencies:
libcompress-zlib-perl: Depends: perlapi-5.8.4 but it is not installable
How to fix that? That's the fault of dh_perl, which uses the
config from Config.pm. And of course the reason for this is in
the first line of dh_perl:
#!/usr/bin/perl -w
I could just hack dh_perl. And I think I will. Nope, still
broken. Oh, except that it's actually running a dh_perl from
scratchbox.
[sbox-CHINOOK_ARMEL: ~/aptitude/libcompress-zlib-perl/libcompress-zlib-perl-1.42] > echo $PATH
/scratchbox/devkits/cputransp/bin:/scratchbox/devkits/maemo3-tools/bin:/scratchbox/devkits/debian-etch/bin:/scratchbox/devkits/perl/bin:/scratchbox/tools/bin:/targets/links/arch_tools/bin:/host_usr/bin:/scratchbox/compilers/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/sbin:/usr/sbin
Remove everything scratchboxy from the path. No, it can't find
find. Put them back, but after the normal ones. No, still
broken. Dammit. OK, nothing for it but to hack the control
file and manually set it to what I know to be the correct
values. Or what I hope I know to be the correct values.
I now, finally, have libcompress-zlib-perl installed. Where was
I? I was compiling libio-zlib-perl. But it fails the unit
tests. But I can install the one from Aeon. Now I can install
libarchive-tar-perl. I also need to copy
libextutils-parsexs-perl and libextutils-cbuilder-perlfrom Aeon.
And libmodule-build-perl is now installed. All of this was for
po4a, which is now going. But it failed like this:
for man in /home/mexon/aptitude/po4a/po4a-0.29/debian/po4a/usr/share/man/man3/*.3pm; do \
sed -i -e 's/ç/\\[,c]/g;s/Ç/\\[,C]/g' $man; \
done
/scratchbox/tools/bin/sed: can't read /home/mexon/aptitude/po4a/po4a-0.29/debian/po4a/usr/share/man/man3/*.3pm: No such file or directory
I'm happy to just comment that part out, so I can get something
installed. Don't upload it though.
Now I have a build dependency on libapt-pkg-dev. But that
depends on libapt-pkg-libc6.4-6-3.11. What happened there? I
don't have any such dependency on Aeon. Oh, oddly enough the
deb is right here. It just hasn't gone into the pool.
Now I'm compiling libpod-coverage-perl. I had to change perl to
perl5.8.3 in the rules file. It built, but I probably have bad
dependencies. No, in fact now it looks good! No, it's broken.
Boo. Ah yes, I was looking at the perl dependency, not the
perlapi dependency. Well, I'll just hack it up again. Which I
just did, and man it would help if, while I was hacking it up, I
actually modified the perl version at the same time.
libtest-pod-coverage is having problems. I'm trying forcing it
to perl5.8.3. Yes, that worked. I work my way back through all
those dependencies and I now have libtest-longstring-perl
installed. Go me.
Now I'm trying to build ical again, but it's grabbing a bunch of
stuff from CPAN. That never ends well. I guess I should pay
attention to what it says and add those as install dependencies
or something. No, wait, that's what the development environment
is supposed to do for me. Well, it didn't, not even close. I
guess I'll just get dependencies sufficient to make it work for
me and leave it at that.
I was fooling around with eperl, and it still refuses to
compile. I think this is because the configure script is
finding the wrong perl. So I'm going to try "cp /usr/bin/perl
~" and "export PATH=~:$PATH". And that worked! Hooray! Ah,
but the wrong perl API again. Hack! Yes, got it working. I
could theoretically have another go at tetex-bin if Maemo wasn't
down.
I need libdatetime-perl in order to run my script too. That
comes with its own massive collection of dependencies. Each of
them seems to be architecture-specific. Which means I have to
double-check the dependencies each time.
I can't even remember why I'm doing this, but I can get poppler
going without QT by simply making and installing it locally.
That was for tetex-bin. No, that doesn't work, complains that
it doesn't know about "FT_Glyph". Forget that, it's
unnecessary. Oh, maemo is back! Hooray!
In aptitude, I was way confused before. I don't, in fact, have
a libapt-pkg-libc6.4-6-3.11 deb. But what the hell is that
package anyway? Aha! Got it! apt-utils provides
libapt-inst-libc6.4-6-1.1. But it depends on
libapt-pkg-libc6.4-6-3.11. OK. I think the problem is that I
have to replace the existing apt utilities, all at once. Yes,
that was it. OK. So the two outstanding items are
libcppunit-dev, which I've got installed locally, and po4a.
Since I installed apt, hildon is all upset:
The following packages have unmet dependencies:
hildon-application-manager: Depends: libapt-pkg-libc6.3-6-3.11
For the moment, I'll install using dpkg. When aptitude is done,
I'll put apt back the way it was. After a lot of fooling
around, aptitude is compiling.
This helps:
aeon:/scratchbox/tools/bin# mkdir disabled
aeon:/scratchbox/tools/bin# mv perl* disabled/
Now let's see if I can compile libdatetime-perl. No, that seemed to be important. What if...
aeon:/scratchbox/tools/bin# ln -s /usr/bin/perl5.8.3 perl
Ah, that makes it run very very slowly. Good. I'm
happy with that. I'll put it back later if I get sick of it.
The nice thing there is that it has the right perl API now.
Aptitude failed like this:
if g++ -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. -I. -I../.. -Wall -I../.. -I. -I../.. -I../../src -DHELPDIR=\"/usr/share/aptitude\" -DPKGDATADIR=\"/usr/share/aptitude\" -g -O2 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -D_REENTRANT -MT columnify.o -MD -MP -MF ".deps/columnify.Tpo" -c -o columnify.o columnify.cc; \
then mv -f ".deps/columnify.Tpo" ".deps/columnify.Po"; else rm -f ".deps/columnify.Tpo"; exit 1; fi
if g++ -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. -I. -I../.. -Wall -I../.. -I. -I../.. -I../../src -DHELPDIR=\"/usr/share/aptitude\" -DPKGDATADIR=\"/usr/share/aptitude\" -g -O2 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -D_REENTRANT -MT transcode.o -MD -MP -MF ".deps/transcode.Tpo" -c -o transcode.o transcode.cc; \
then mv -f ".deps/transcode.Tpo" ".deps/transcode.Po"; else rm -f ".deps/transcode.Tpo"; exit 1; fi
transcode.cc: In function `bool transcode(const char*, std::wstring&, const char*)':
transcode.cc:229: error: `CODESET' undeclared (first use this function)
transcode.cc:229: error: (Each undeclared identifier is reported only once for each function it appears in.)
transcode.cc:229: error: `nl_langinfo' undeclared (first use this function)
transcode.cc: In function `bool transcode(const wchar_t*, std::string&, const char*)':
transcode.cc:294: error: `CODESET' undeclared (first use this function)
transcode.cc:294: error: `nl_langinfo' undeclared (first use this function)
make[5]: *** [transcode.o] Error 1
make[5]: Leaving directory `/home/mexon/aptitude/aptitude/aptitude-0.4.4/src/vscreen'
make[4]: *** [all-recursive] Error 1
Abandon that. For my script, I just need Date::Parse. Which
comes from libtimedate-perl. Oh, fails like this:
Base class package "Class::Accessor" is empty.
(Perhaps you need to 'use' the module which defines that package first.)
at /usr/share/perl5/Data/ICal/Entry.pm line 5
In other words, libclass-accessor-perl is an install dependency
of libdata-ical-perl. So is libclass-returnvalue-perl. Which
requires a massive build dependency tree to be installed. All
of them were for all architectures though, so it was OK to grab
them from Aeon. Also libtext-vfile-asdata-perl. And that one
appears to be from the plagger repository. So I'm going to have
to compile it myself. Wait, it's in Lenny. That'll do.
OK, tell you what, at this stage I'm going to start importing
these perl modules directly into the repository. That'll make
life a whole lot easier. Hmm, that didn't work.
OK, I made it work, by doing this:
reprepro -P normal -S main --ignore=wrongdistribution -Vb /var/www/apt includedeb chinook libtext-vfile-asdata-perl_0.0.5-4_all.deb
...and by, after lots of confusion, remembering to reset the
permissions. Another dependency is libdata-ical-timezone-perl.
Which I just can't find anywhere. So I guess I have to do this
one from CPAN.
A dependency of libdata-ical-timezone-perl is libuniversal-require-perl.
I think I got those uploaded. In the meantime, I realised I
still haven't tested out freshly installing dovecot. So I'm
doing that. And I have a problem: it still seems to be loading
libpq3. But I think I never got around to uploading the newer
version of dovecot. The other thing to test is whether it
automatically brings in libpam-modules.
No, still failing. Bugger. That really sucks. How did that
happen? It was working before.
At least apt-get install libdata-ical-timezone-perl works
correctly. The other packages I need are libtimedate-perl and
libdatetime-timezone-perl. And libdatetime-perl. I forgot to
make libtext-vfile-asdata-perl a dependency for one of the
libdata-ical things.
However, my perl script now works. Hooray!
Anyway, dovecot. It seems that the problem lies in
/usr/lib/dovecot/dovecot-auth. Except that it's asking for
libpq.so.5. Ah! Did I uninstall dovecot-common before
reinstalling? For the record, dovecot-common pulls in libpq as
a dependency. And now it works! Hurrah!
Matthew Exon
Last modified: Mon Feb 18 22:05:33 CET 2008