amd64 bulk build failures 2014-07-16

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

amd64 bulk build failures 2014-07-16

Christian Weisgerber
Here's the breakage from the 2014-07-16 amd64 bulk build:

devel/hyena                     mono (Mono.Cairo)
devel/kdevelop                  missing ui_custom_include_paths.h
devel/monodevelop               mono
devel/msp430/gcc                gengtype internal error
games/alephone/weland           mono (Mono.Cairo)
graphics/digikam-kde4           cmake opencv
lang/mono-basic                 mono
mail/dovecot                    ssl compression
sysutils/gsmartcontrol          missing libres.a
x11/kde4/artwork                files missing at packaging
x11/xfce4/tumbler               /usr/local/bin/gtkdoc-rebase not found

kde4/artwork and digikam-kde4 should already be fixed from the
commit messages I've seen.

This build also contained pascal@'s sys.mk patch for adding default
rules for .cpp files.  I don't think any errors can be attributed
to that, although somebody might want to double-check gsmartcontrol.

Build time without softupdates appears to have increased by an hour
or two (for a total of about 32h).

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: amd64 bulk build failures 2014-07-16

Vadim Zhukov
2014-07-18 13:49 GMT+02:00 Christian Weisgerber <[hidden email]>:
> devel/kdevelop                  missing ui_custom_include_paths.h

I need a build log (at least the whole part containing error message
and corresponding compilation line) to develop a fix.

> x11/xfce4/tumbler               /usr/local/bin/gtkdoc-rebase not found

Will fix ASAP.

> kde4/artwork and digikam-kde4 should already be fixed from the
> commit messages I've seen.

Yes.

--
  WBR,
  Vadim Zhukov

Reply | Threaded
Open this post in threaded view
|

Re: amd64 bulk build failures 2014-07-16

Vadim Zhukov
2014-07-18 13:55 GMT+02:00 Vadim Zhukov <[hidden email]>:
> 2014-07-18 13:49 GMT+02:00 Christian Weisgerber <[hidden email]>:
>> devel/kdevelop                  missing ui_custom_include_paths.h
>
> I need a build log (at least the whole part containing error message
> and corresponding compilation line) to develop a fix.
>
>> x11/xfce4/tumbler               /usr/local/bin/gtkdoc-rebase not found
>
> Will fix ASAP.

Oh, misread this as x11/kde4/tumbler. ENOCOFFEE

>> kde4/artwork and digikam-kde4 should already be fixed from the
>> commit messages I've seen.
>
> Yes.

--
  WBR,
  Vadim Zhukov

Reply | Threaded
Open this post in threaded view
|

Re: amd64 bulk build failures 2014-07-16

Stuart Henderson-6
In reply to this post by Vadim Zhukov
On 2014/07/18 13:55, Vadim Zhukov wrote:
> 2014-07-18 13:49 GMT+02:00 Christian Weisgerber <[hidden email]>:
> > devel/kdevelop                  missing ui_custom_include_paths.h
>
> I need a build log (at least the whole part containing error message
> and corresponding compilation line) to develop a fix.

I'll send one offlist

Reply | Threaded
Open this post in threaded view
|

Re: amd64 bulk build failures 2014-07-16

Antoine Jacoutot-7
In reply to this post by Christian Weisgerber
> devel/hyena                     mono (Mono.Cairo)

robert, could you have a look please. devel/hyena is a dependency of pdfmod which I find handy.

--
Antoine

Reply | Threaded
Open this post in threaded view
|

Re: amd64 bulk build failures 2014-07-16

Robert Nagy
sure

On (2014-07-18 18:40), Antoine Jacoutot wrote:
> > devel/hyena                     mono (Mono.Cairo)
>
> robert, could you have a look please. devel/hyena is a dependency of pdfmod which I find handy.
>
> --
> Antoine
>

Reply | Threaded
Open this post in threaded view
|

Re: amd64 bulk build failures 2014-07-16

Vadim Zhukov
In reply to this post by Christian Weisgerber
This should fix kdevelop build failures. Build on i386 went fine.


Index: patches/patch-languages_cpp_CMakeLists_txt
===================================================================
RCS file: patches/patch-languages_cpp_CMakeLists_txt
diff -N patches/patch-languages_cpp_CMakeLists_txt
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-languages_cpp_CMakeLists_txt 18 Jul 2014 21:35:55 -0000
@@ -0,0 +1,13 @@
+$OpenBSD$
+--- languages/cpp/CMakeLists.txt.orig Sat Jul 19 01:00:03 2014
++++ languages/cpp/CMakeLists.txt Sat Jul 19 01:00:12 2014
+@@ -88,6 +88,9 @@ target_link_libraries(kdevcpplanguagesupport
+     ${KDE4_KTEXTEDITOR_LIBS}
+ )
+
++# XXX should be done directly in KDE4Macros.cmake instead?
++add_dependencies(kdevcpplanguagesupport ${CMAKE_CURRENT_BINARY_DIR}/ui_custom_include_paths.h)
++
+ install(TARGETS kdevcpplanguagesupport DESTINATION ${PLUGIN_INSTALL_DIR})
+
+

Reply | Threaded
Open this post in threaded view
|

Re: amd64 bulk build failures 2014-07-16

Christian Weisgerber
Vadim Zhukov:

> This should fix kdevelop build failures. Build on i386 went fine.

I'm afraid not.  The build on amd64.ports failed again.
(I assume it is some kind of race condition or depends on ninja's
random build order.)

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: amd64 bulk build failures 2014-07-16

Christian Weisgerber
In reply to this post by Christian Weisgerber
On 2014-07-18, Christian Weisgerber <[hidden email]> wrote:

> This build also contained pascal@'s sys.mk patch for adding default
> rules for .cpp files.  I don't think any errors can be attributed
> to that, although somebody might want to double-check gsmartcontrol.

gsmartcontrol is indeed fallout from the sys.mk diff.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: amd64 bulk build failures 2014-07-16

Pascal Stumpf
On Sat, 19 Jul 2014 23:29:58 +0000 (UTC), Christian Weisgerber wrote:
> On 2014-07-18, Christian Weisgerber <[hidden email]> wrote:
>
> > This build also contained pascal@'s sys.mk patch for adding default
> > rules for .cpp files.  I don't think any errors can be attributed
> > to that, although somebody might want to double-check gsmartcontrol.
>
> gsmartcontrol is indeed fallout from the sys.mk diff.

Easily fixed by removing the rules for {ui,glade}.cpp targets.  They
don't need to be remade as they already exist in the distribution
tarball.

Alternatively, the port could also switch to gmake, where the workaround
in the Makefile itself (setting SUFFIXES) will work.

Index: patches/patch-src_res_Makefile_in
===================================================================
RCS file: patches/patch-src_res_Makefile_in
diff -N patches/patch-src_res_Makefile_in
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_res_Makefile_in 20 Jul 2014 11:14:59 -0000
@@ -0,0 +1,13 @@
+$OpenBSD$
+--- src/res/Makefile.in.orig Sun Jul 20 13:10:41 2014
++++ src/res/Makefile.in Sun Jul 20 13:11:00 2014
+@@ -517,9 +517,6 @@ uninstall-am:
+ mostlyclean-local:
+ rm -f *.glade.cpp *.ui.cpp *.tmp_ui *.txt.cpp
+
+-# This lists the actual makefile rules for each target.
+-@RES_TARGETS@
+-
+ # # List all local resource files here. Note: noinst_DATA doesn't put them into distribution (why?)
+ # EXTRA_DIST = gsc_about_dialog.glade gsc_executor_log_window.glade \
+ # gsc_help_window.glade gsc_info_window.glade gsc_main_window.glade \

Reply | Threaded
Open this post in threaded view
|

Re: amd64 bulk build failures 2014-07-16

Marc Espie-2
On Sun, Jul 20, 2014 at 01:17:08PM +0200, Pascal Stumpf wrote:

> On Sat, 19 Jul 2014 23:29:58 +0000 (UTC), Christian Weisgerber wrote:
> > On 2014-07-18, Christian Weisgerber <[hidden email]> wrote:
> >
> > > This build also contained pascal@'s sys.mk patch for adding default
> > > rules for .cpp files.  I don't think any errors can be attributed
> > > to that, although somebody might want to double-check gsmartcontrol.
> >
> > gsmartcontrol is indeed fallout from the sys.mk diff.
>
> Easily fixed by removing the rules for {ui,glade}.cpp targets.  They
> don't need to be remade as they already exist in the distribution
> tarball.
>
> Alternatively, the port could also switch to gmake, where the workaround
> in the Makefile itself (setting SUFFIXES) will work.

Nope... the idea is definitely NOT to force ports to move to gmake. That
amount to breaking our make!!!