more detailed testing migration info ...
Hello, ...
I have been looking a bit more, and i think these are the remaining
issues :
1) First problem :
o cameleon (sparc)
o meta-ocaml ( all arches ) #180967 depends on zoggy, which is
unavailable (for sparc i guess)
This is the problem we worked around for sparc, Jerome, can you upload a
fixed package ? You can apply the following patch to configure :
--- patch ---
--- ocaml-3.06-3.06.orig/configure
+++ ocaml-3.06-3.06/configure
@@ -385,17 +385,21 @@
# Determine alignment constraints
-sh ./runtest dblalign.c
-case $? in
- 0) echo "Doubles can be word-aligned."
- echo "#undef ARCH_ALIGN_DOUBLE" >> m.h;;
- 1) echo "Doubles must be doubleword-aligned."
- echo "#define ARCH_ALIGN_DOUBLE" >> m.h;;
- *) echo "Something went wrong during alignment determination for doubles."
- echo "I'm going to assume this architecture has alignment constraints over doubles."
- echo "That's a safe bet: Objective Caml will work even if"
- echo "this architecture has actually no alignment constraints."
- echo "#define ARCH_ALIGN_DOUBLE" >> m.h;;
+case "$host" in
+ sparc*-*-*) echo "Doubles must be doubleword-aligned."
+ echo "#define ARCH_ALIGN_DOUBLE" >> m.h;;
+ *) sh ./runtest dblalign.c
+ case $? in
+ 0) echo "Doubles can be word-aligned."
+ echo "#undef ARCH_ALIGN_DOUBLE" >> m.h;;
+ 1) echo "Doubles must be doubleword-aligned."
+ echo "#define ARCH_ALIGN_DOUBLE" >> m.h;;
+ *) echo "Something went wrong during alignment determination for doubles."
+ echo "I'm going to assume this architecture has alignment constraints over doubles."
+ echo "That's a safe bet: Objective Caml will work even if"
+ echo "this architecture has actually no alignment constraints."
+ echo "#define ARCH_ALIGN_DOUBLE" >> m.h;;
+ esac;;
esac
if $int64_native; then
--- patch ---
2) problem :
o netclient (ia64) Need ocamlnet, last try november 28.
o ocamlnet (ia64) need libpcre-ocaml-dev, last try november 28.
o pxp (ia64) needs ocamlnet
o shell (ia64) didn't build on december 20 because ocaml-findlib was
not yet rebuilt for ocaml-3.06-1. findlib was rebuilt on december 25.
o wlex (ia64) same as above.
o xstr (ia64) same as above.
So, i think this is no real problem, we just need to reschedule a build
of these packages, i will take care of it, and ask bdale to schedule
rebuilds of those, since both ocamlfindlib and libpcre-ocaml are valid
candidate now.
3)
o lablgtkmathview (hppa mipsel)
o gmetadom (hppa) + #174246 (some -fPIC problems with shared objects).
Well, there are 2 different problems. First there is the hppa problem.
lablgtkmathview depends on gmetadom which FTBFS because of #174246. This
bug is 70 days old, Stefano, do you have an idea of what is causing it ?
The mipsel problem is linked with libgtkmathview-dev, which fails to
build for both mipsel and hppa. It fails to build on mipsel because the
mipsel auto-builder uses rsudo, and apparently it is just a build
problem, probably a failure to properly clean the config.log file.
THe FTBFS bug is #178877,
4)
o gdome2-xsl (i386) #182305.
This is a problem since gdome2-xsl apparently depends on an older
version of gmetadom (since it declares the libgdome2-ocaml-dev-0.1.4
build-dependency), but gmetadom is already 0.1.5. Still, this package
was not in testing, so it should not cause us any problem.
5)
o camlidl ( all arches ) #174532.
Here it apparently is a problem with the installation of camlidl-doc.
Summary
=======
Unless i have missed something, the problems that need to be solved are
twofold, first the problem 1 with cameleon on sparc, but we have a
patch, and Jerome only needs to reupload, or maybe do a binary-only
re-upload on sparc or something such and the problem 2, which should
only need a rebuild on ia64. Second, there is problem 3 and 5. The
problem 3 on mipsel should be easy to resolve, and seem to be a sudo
build issue (i had this also in ocaml or lablgtk, don't remember). The
camlidl-doc should also be only a configuration issue, and should be
easy to solve. #174246 is the more difficult of all, i think, altough
maybe if the corresponding lib is rebuilt with -fPIC, it should go away,
so it may also be only a configuration issue.
Now, all these are Stefano's package, who is quite busy right now. If he
does not have time, i think it would be ok if someone else could have a
look at it, and that we do an NMU of those if needed (is that ok with you,
Stefano ?). Ralf, could you perhaps have a look at #174532 that you
submitted ? And we could fix #175438 which seems plain enough at the
same time.
Friendly,
Sven Luther
Reply to: