2086
Comment:
|
2520
added note about build failure with new GTK+
|
Deletions are marked like this. | Additions are marked like this. |
Line 50: | Line 50: |
== 2007-09-29 Packages failing to build with GTK+ 2.12 (symbol errors on GTK_TOOLTIPS, gtk_widget_unref and more) == GTK+ 2.12 deprecated a bunch of API and packages that define GTK_DISABLE_DEPRECATED now fail to build. Easy solution is to remove GTK_DISABLE_DEPRECATED from CFLAGS; better solution is to port to newer API (upstream may already have done it). * gtk_widget_ref -> g_object_ref * GtkTooltips -> GtkTooltip |
This page lists details about build failures that affect several pages (and the "good" way to solve them).
2007-08-28 Packages failing because of missing camlp4o
Quite some packages fail because camlp4 has been moved from ocaml-nox's Build-Depends to Recommends. The Ocaml team has tightened their Build-Depends and wants the Packages B-D on caml4p directly:
09:35 <abi> as of the recent rebuild sid/x86 about ~10 packages FTBFS because of missing camlp4o, do the packages have to Build-Depend on camlp4 or would it make more sense to move it from the Recommends to Depends in ocaml-nox
09:35 <abi> i just wonder if i should file the bug for the packages or ocaml-nox 09:36 <smimou> well I think that we should tighten our build-deps instead
09:37 <smimou> we have already started doing this
09:37 <abi> ok, so im going to file the bugs against the packages rather than ocaml-nox?
09:37 <smimou> yes, please
09:38 <smimou> camlp4 is quite a big package so I'd rather avoid ocaml depending on it
2007-09-12 Packages failing due to undetected libdb
[http://bugs.debian.org/441763 #441763] (libdb4.2): “libdb-4.2.so must link against libpthread”
[http://bugs.debian.org/441870 #441870] (libdb4.3-dev): “libdb.so must link against libpthread”.
Please block those FTBFSes with the appropriate libdb bug. -- CyrilBrulebois
2007-09-14 Packages failing to build with ecj-gcj due to missing java.lang.object
[http://bugs.debian.org/441660 #441660] tex4ht: FTBFS: The type java.lang.Object cannot be resolved
Somewhere between 3.3.0+0728-1 and 3.3.0+0728-4 "ecj" dropped its dependency on gij which was used to build it. Packages should build fine with 3.3.0+0728-5 upwards. -- KapilHariParanjape
2007-09-17 Packages failing to build cause of "called object 'major' is not a function"
nfs-utils fixed it this way (#442122, from 09-define-major-minor.patch):
#ifndef major # define major(dev) gnu_dev_major (dev) #endif #ifndef minor # define minor(dev) gnu_dev_minor (dev) #endif [..]
2007-09-29 Packages failing to build with GTK+ 2.12 (symbol errors on GTK_TOOLTIPS, gtk_widget_unref and more)
GTK+ 2.12 deprecated a bunch of API and packages that define GTK_DISABLE_DEPRECATED now fail to build. Easy solution is to remove GTK_DISABLE_DEPRECATED from CFLAGS; better solution is to port to newer API (upstream may already have done it).