Your message dated Fri, 13 Jan 2017 08:42:11 +0100
with message-id <20170113074211.suqhg3osivclu...@surf-1-it-3-601.aa-internet>
and subject line Re: Bug#850984: Bug#850972: firefox: FTBFS: configure: error:
cannot determine icu version number from uvernum.h header file
has caused the Debian Bug report #850984,
regarding icedove: FTBFS: configure: error: cannot determine icu version number
from uvernum.h header file
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
850984: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850984
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: icedove
Version: 1:45.5.1-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170111 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of all packages in sid, your package failed to build on
amd64.
Relevant part (hopefully):
> checking for posix_fallocate... yes
> checking for icu-i18n >= 50.1... yes
> checking MOZ_ICU_CFLAGS...
> checking MOZ_ICU_LIBS... -licui18n -licuuc -licudata
> sed: character class syntax is [[:space:]], not [:space:]
> configure: error: cannot determine icu version number from uvernum.h header
> file
> ------ config.log ------
> configure:28359: gcc -c -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=.
> -fstack-protector-strong -Wformat -Werror=format-security
> -fno-delete-null-pointer-checks -fno-schedule-insns2 -std=gnu99
> -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections
> -fno-math-errno -pthread -pipe -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c 1>&5
> configure:28346: checking for inttypes.h
> configure:28359: gcc -c -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=.
> -fstack-protector-strong -Wformat -Werror=format-security
> -fno-delete-null-pointer-checks -fno-schedule-insns2 -std=gnu99
> -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections
> -fno-math-errno -pthread -pipe -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c 1>&5
> configure:28610: checking for cairo >= 1.10
> configure:28617: checking CAIRO_CFLAGS
> configure:28622: checking CAIRO_LIBS
> configure:28703: checking for cairo-tee >= 1.10
> configure:28710: checking CAIRO_TEE_CFLAGS
> configure:28715: checking CAIRO_TEE_LIBS
> configure:28795: checking for cairo-xlib-xrender >= 1.10
> configure:28802: checking CAIRO_XRENDER_CFLAGS
> configure:28807: checking CAIRO_XRENDER_LIBS
> configure:29789: checking for posix_fadvise
> configure:29821: gcc -o conftest -Wall -Wempty-body -Wpointer-to-int-cast
> -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -g -O2
> -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat
> -Werror=format-security -fno-delete-null-pointer-checks -fno-schedule-insns2
> -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections
> -fdata-sections -fno-math-errno -pthread -pipe -Wdate-time
> -D_FORTIFY_SOURCE=2 -lpthread -Wl,-z,relro -Wl,--no-keep-memory
> -Wl,--reduce-memory-overheads -Wl,--stats -Wl,-z,noexecstack -Wl,-z,text
> -Wl,--build-id conftest.c -ldl 1>&5
> /usr/bin/ld: total time in link: 0.020000
> /usr/bin/ld: data size 0
> configure:29789: checking for posix_fallocate
> configure:29821: gcc -o conftest -Wall -Wempty-body -Wpointer-to-int-cast
> -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -g -O2
> -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat
> -Werror=format-security -fno-delete-null-pointer-checks -fno-schedule-insns2
> -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections
> -fdata-sections -fno-math-errno -pthread -pipe -Wdate-time
> -D_FORTIFY_SOURCE=2 -lpthread -Wl,-z,relro -Wl,--no-keep-memory
> -Wl,--reduce-memory-overheads -Wl,--stats -Wl,-z,noexecstack -Wl,-z,text
> -Wl,--build-id conftest.c -ldl 1>&5
> /usr/bin/ld: total time in link: 0.020000
> /usr/bin/ld: data size 4354048
> configure:29875: gcc -c -Wall -Wempty-body -Wpointer-to-int-cast
> -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -g -O2
> -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat
> -Werror=format-security -fno-delete-null-pointer-checks -fno-schedule-insns2
> -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections
> -fdata-sections -fno-math-errno -pthread -pipe -Wdate-time
> -D_FORTIFY_SOURCE=2 conftest.c 1>&5
> configure:30104: checking for icu-i18n >= 50.1
> configure:30111: checking MOZ_ICU_CFLAGS
> configure:30116: checking MOZ_ICU_LIBS
> configure: error: cannot determine icu version number from uvernum.h header
> file
> *** Fix above errors and then restart with\
> "make -f client.mk build"
> client.mk:361: recipe for target 'configure' failed
> make[2]: *** [configure] Error 1
> make[2]: Leaving directory '/<<PKGBUILDDIR>>'
> debian/rules:68: recipe for target 'override_dh_auto_configure' failed
> make[1]: *** [override_dh_auto_configure] Error 2
> make[1]: Leaving directory '/<<PKGBUILDDIR>>'
> debian/rules:58: recipe for target 'build' failed
The full build log is available from:
http://aws-logs.debian.net/2017/01/11/icedove_45.5.1-1_unstable.log
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.
--- End Message ---
--- Begin Message ---
Version: 1:45.6.0-2
Hello John,
On Thu, Jan 12, 2017 at 11:39:42PM +0100, John Paul Adrian Glaubitz wrote:
> On 01/12/2017 10:48 PM, Mike Hommey wrote:
> >> What about Icedove? Should we cherry-pick the patch in this case?
> >
> > Icedove uses Firefox code base upstream, so it will end up there
> > mechanically.
>
> Yep, I'm aware of that. I was actually referring to the Debian icedove
> package but as it seems Carsten was already quick enough to address the
> issue even before the bug report was filed ;).
>
> @Carsten: I assume we can close #850984 then?
yes, I will do with this email.
As Mike has written, the import of the next uptream version will end in
resolving the current added patch and the last upload was building fine
except the known issues on mips*.
Regards
Carsten
--- End Message ---
