Launchpad itself

Launchpad Repetitive Build Error fot gtkpod (50 % error rate)

Asked by Pascal Mons

It looks like Launchpad stumble on 2 attempts to build gtkpod 2.1.5 out of 4 submissions. in my PPA

https://launchpad.net/~anton+/+archive/ubuntu/photo-video-apps

What is striking is that it stumbles on the very same item (alleged file missing ... from the source)

Build for Trusty 14.04 i386 [successful] : https://launchpadlibrarian.net/218931478/buildlog_ubuntu-trusty-i386.gtkpod_2.1.5-1pmo2~trusty_BUILDING.txt.gz

Build for Trusty 14.04 amd64 [failed] : https://launchpadlibrarian.net/218931449/buildlog_ubuntu-trusty-amd64.gtkpod_2.1.5-1pmo2~trusty_BUILDING.txt.gz

Build for Wily 15.10 i386 [successful] : https://launchpadlibrarian.net/218933587/buildlog_ubuntu-wily-i386.gtkpod_2.1.5-1pmo2.1~wily_BUILDING.txt.gz

Build for Wily 15.10 amd64 [failed] : https://launchpadlibrarian.net/218933529/buildlog_ubuntu-wily-amd64.gtkpod_2.1.5-1pmo2.1~wily_BUILDING.txt.gz

Namely, on the build for Trusty 14.04 and Wily 15.10 the i386 architecture was successful however the amd64 failed. Here is the error : (missing file rhythmbox.gep which is present in the source ...)

make[3]: Leaving directory `/«PKGBUILDDIR»/plugins/clarity'
Making install in sjcd
make[3]: Entering directory `/«PKGBUILDDIR»/plugins/sjcd'
Making install in data
make[4]: Entering directory `/«PKGBUILDDIR»/plugins/sjcd/data'
if [ ! -e ../../../data/rhythmbox.gep ]; then \
  ln -s `pwd`/rhythmbox.gep ../../../data/rhythmbox.gep; \
 fi;
make[5]: Entering directory `/«PKGBUILDDIR»/plugins/sjcd/data'
make[5]: Nothing to be done for `install-exec-am'.
 /bin/mkdir -p '/«PKGBUILDDIR»/debian/tmp/usr/share/gtkpod/data'
 /bin/mkdir -p '/«PKGBUILDDIR»/debian/tmp/usr/share/gtkpod/data'
if test -n "org.gtkpod.sjcd.gschema.xml"; then \
  test -z "/usr/share/glib-2.0/schemas" || /bin/mkdir -p "/«PKGBUILDDIR»/debian/tmp/usr/share/glib-2.0/schemas"; \
  /usr/bin/install -c -m 644 org.gtkpod.sjcd.gschema.xml "/«PKGBUILDDIR»/debian/tmp/usr/share/glib-2.0/schemas"; \
  test -n "/«PKGBUILDDIR»/debian/tmp" || /usr/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas /usr/share/glib-2.0/schemas; \
 fi
 /usr/bin/install -c -m 644 rhythmbox.gep '/«PKGBUILDDIR»/debian/tmp/usr/share/gtkpod/data'
 /usr/bin/install -c -m 644 rhythmbox.gep '/«PKGBUILDDIR»/debian/tmp/usr/share/gtkpod/data'
/usr/bin/install: cannot change permissions of '/«PKGBUILDDIR»/debian/tmp/usr/share/gtkpod/data/rhythmbox.gep': No such file or directory
make[5]: *** [install-profilesDATA] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: Leaving directory `/«PKGBUILDDIR»/plugins/sjcd/data'

While on the i386 architecture we have :

make[3]: Leaving directory `/«PKGBUILDDIR»/plugins/clarity'
Making install in sjcd
make[3]: Entering directory `/«PKGBUILDDIR»/plugins/sjcd'
Making install in data
make[4]: Entering directory `/«PKGBUILDDIR»/plugins/sjcd/data'
if [ ! -e ../../../data/rhythmbox.gep ]; then \
  ln -s `pwd`/rhythmbox.gep ../../../data/rhythmbox.gep; \
 fi;
make[5]: Entering directory `/«PKGBUILDDIR»/plugins/sjcd/data'
make[5]: Nothing to be done for `install-exec-am'.
 /bin/mkdir -p '/«PKGBUILDDIR»/debian/tmp/usr/share/gtkpod/data'
 /bin/mkdir -p '/«PKGBUILDDIR»/debian/tmp/usr/share/gtkpod/data'
if test -n "org.gtkpod.sjcd.gschema.xml"; then \
  test -z "/usr/share/glib-2.0/schemas" || /bin/mkdir -p "/«PKGBUILDDIR»/debian/tmp/usr/share/glib-2.0/schemas"; \
  /usr/bin/install -c -m 644 org.gtkpod.sjcd.gschema.xml "/«PKGBUILDDIR»/debian/tmp/usr/share/glib-2.0/schemas"; \
  test -n "/«PKGBUILDDIR»/debian/tmp" || /usr/lib/i386-linux-gnu/glib-2.0/glib-compile-schemas /usr/share/glib-2.0/schemas; \
 fi
 /usr/bin/install -c -m 644 rhythmbox.gep '/«PKGBUILDDIR»/debian/tmp/usr/share/gtkpod/data'
 /usr/bin/install -c -m 644 rhythmbox.gep '/«PKGBUILDDIR»/debian/tmp/usr/share/gtkpod/data'
make[5]: Leaving directory `/«PKGBUILDDIR»/plugins/sjcd/data'
make[4]: Leaving directory `/«PKGBUILDDIR»/plugins/sjcd/data'

I double checked on my amd64 computer (Trusty 14.04) and it compiled flawlessly).

Then I resubmitted the job with the same debian and source for Trusty version 2.1.5-1pmo2.1 and this time it succeeded.

I have yet to resubmit the job for Wily 15.10.

However I find this troubling as it points to a 50 % error rate from the Launchpad building process.

Do you have any clues ?

Question information

Language:
English Edit question
Status:
Answered
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
William Grant (wgrant) said : 		#1

Have you tried building locally with DEB_BUILD_OPTIONS=parallel=4? 50% failure sounds like a race condition in the build process.

Revision history for this message
Pascal Mons (anton+) said : 		#2

The 50 % rate was on 4 builds. I mean Vivid 15.04 succeeded the first time. Then Trusty failed on amd64. Retrying on Trusty was successful (this is 2 attempts to succeed). However I had to try 3 times to get through with Wily 15.10.

I didn't change anything in the debian folder when I tried on my computer. This is a python2 build. I don't know how to force use of 4 processors in Python ...

Here is the debian file :

#!/usr/bin/make -f
export DH_OPTIONS

DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

# Substitute CXXFLAGS from -O2 to -O3 for optimized Quad Core compilation
# http://manpages.ubuntu.com/manpages/precise/man1/dpkg-buildflags.1.html
# https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
export DEB_CFLAGS_MAINT_STRIP := -O2
export DEB_CXXFLAGS_MAINT_STRIP := -O2
export DEB_CFLAGS_MAINT_APPEND := -O3
export DEB_CXXFLAGS_MAINT_APPEND := -O3

%:
 dh $@ --with python2,pkgkde_symbolshelper,autoreconf --parallel

override_dh_install:
 rm -f debian/tmp/usr/share/gtkpod/data/COPYING
 rm -f debian/tmp/usr/share/gtkpod/doc/icon-licence.txt
 dh_install

override_dh_strip:
 dh_strip --dbg-package=gtkpod-dbg

override_dh_builddeb:
 dh_builddeb -- -Zxz -z9

However when building on Launchpad I attempted to see what was happening on both architecture while processing by opening the links.

It looks like the build succeeded when the i386 and amd64 are far apart in time. When they are close of doing the same thing the build failed.

On my computer I build only one architecture of course.

One time I had the error for Willy as the file (always) the same already existed. Hence it can't create it.
Previously I had the error the file doesn't exist in Trusty.

It looks like there is some interaction between architecture where it shouldn’t be in the first place ?

Revision history for this message
William Grant (wgrant) said : 		#3

If you're not building in parallel locally then you're not matching Launchpad's build environment. Ensure that DEB_BUILD_OPTIONS=parallel=4 is set in your environment when you run debuild or dpkg-buildpackage, otherwise you'll get a sequential build.

Revision history for this message
Colin Watson (cjwatson) said : 		#4

As William says, this is a bug exposed by parallel building. (Whether the i386 and amd64 builds happen close in time is immaterial; this is just a question of the human brain being very good at spotting patterns, sometimes even those that aren't there! There is no interaction between architectures here.) The bug is in plugins/sjcd/data/Makefile.am, which reads, in part:

profiles_DATA = rhythmbox.gep
dist_profiles_DATA = rhythmbox.gep
[...]
EXTRA_DIST = \
        $(profiles_DATA) \
        $(schema_in_files)

This is buggy in two different ways. Firstly, $(profiles_DATA) does not need to be in EXTRA_DIST; that's redundant given that dist_profiles_DATA is already declared. That doesn't cause your problem, though it ought to be tidied up anyway. Secondly, and this is the cause of your problem, the same file should not be in both profiles_DATA and dist_profiles_DATA; it's sufficient for it just to be in dist_profiles_DATA. When it's present in both, then a parallel build will try to run two identical install commands at the same time. What happens then depends on the exact timing of the system calls made by those two commands relative to each other: depending on how they happen to be interleaved, they may both succeed or (as you sometimes see) one may fail.

To summarise, you should apply the untested patch in http://paste.ubuntu.com/12593117/, and if it works then please send it upstream as well.

Can you help with this problem?

Provide an answer of your own, or ask Pascal Mons for more information if necessary.

To post a message you must log in.