Hi Paul, Here are a couple of comments that will hopefully take you one step further: - The build.conf that you are using below is tracking the latest and greatest. To be completely aligned with how things were built for the Tizen IVI 3.0-M2-Aug image, you should be using the corresponding build.conf (that is published along with the image here (under builddata): http://download.tizen.org/releases/milestone/tizen/ivi/latest/builddata/2136ea2bb2baac8eab4317d2df3f5bbeec8de251cf8ee300d1c669b9639280ff-build.conf. - You are also including this repo when doing a rebuild: [repo.tizen3.0_ivi] url=http://download.tizen.org/releases/daily/tizen/ivi/latest/ GBS will be picking packages from it that were not part of the Aug preview. A full rebuild from sources would mean you should only use the pre-built binaries (i.e. the repo.tizen3.0_x86 whose tag/commit ID corresponds to the release/preview you want to rebuild). In my opinion, this is a missing line item that should also be included in the manifest.xml file published with the images... I have filed a bug for this (https://bugs.tizen.org/jira/browse/DEVT-96) - I haven't checked lately but GBS should also be able to handle remote 'upstream' branches. This has been reported to the Tools Development team so maybe it's been addressed already.
Geoffroy PS: You don't need to include the '-u review.tizen.org:/scm/manifest' parameter when using 'repo init' given the manifest.xml has been copied locally in .repo/manifests. I don't _think_ however that keeping it has any side-effect and is the reason you're seeing the failure. From: [email protected] [mailto:[email protected]] On Behalf Of Hanchett, Paul Sent: Thursday, September 12, 2013 7:32 PM To: [email protected] Subject: (Re)Building the IVI M2 Aug release I am trying to recreate the IVI M2 Aug release, using the manifest file and process suggested by Geoffroy to us so we could get the same sources used for IVI M2 Aug: To do that, I created a new working directory. I got the manifest file, changed the name of libslp-tapi to libtapi (as suggested else where), and also commented out the project tag referencing "web/wrt". Then I copied the resulting manifest into .repo/manifests/tizen_20130829.9-ivi-release-mbr-i586.manifest.xml. I used this script to init and sync the work directory: # # Initialize the repository to Tizen 3.0 IVI M2 Aug branch, warts and all. # export USER="paulha" echo Initialize the repository to Tizen 3.0 IVI M2 Aug branch, warts and all. echo repo init -u ssh://[email protected]/scm/manifest<http://[email protected]/scm/manifest> -m tizen_20130829.9-ivi-release-mbr-i586.manifest.xml repo init -u ssh://[email protected]/scm/manifest<http://[email protected]/scm/manifest> -m tizen_20130829.9-ivi-release-mbr-i586.manifest.xml echo repo sync repo sync I put this .gbs.conf script into the working directory, with buildroot pointing at a new build root: [general] tmpdir=/var/tmp/ # -- Use this profile as a default profile = profile.tizen3.0 # -- 'tizen' is the Tizen 3.0 (ivi) branch packaging_branch = tizen editor = vim work_dir=. buildroot = ~/GBS-TIZEN-3.0M2 [obs.tizen] url = https://api.tizen.org [repo.tizen3.0_x86] url=${work_dir}/pre-built/toolchain-x86/ [repo.tizen3.0_ivi] url=http://download.tizen.org/releases/daily/tizen/ivi/latest/ [profile.tizen3.0] obs = obs.tizen # refers back to earlier sections repos=repo.tizen3.0_x86,repo.tizen3.0_ivi buildconf=${work_dir}/scm/meta/build-config/build.conf Then I invoked my build script: echo ================================================================================================== echo gbs build -A i586 --threads 2 --clean-once --exclude=gcc,cmake,filesystem,aul,libmmsound,libtool,systemd echo ================================================================================================== gbs build -A i586 --threads 2 --clean-once --exclude=gcc,cmake,filesystem,aul,libmmsound,libtool,systemd echo DONE. Note that "systemd" has been added to the exclude list because an initial pass reported a circularity error systemd->dbus->systemd. I ended up with some 195 packages built, and around 70 with 5 classes of errors: 54 instances of Conflict between libstdc++ 4.7 and 4.8 Looks like this: [ 64s] [90/156] installing libstdc++-4.8.1-1.20 [ 64s] [91/156] installing libstdc++47-4.7.2-2.11 [ 64s] file /usr/lib/libstdc++.so.6 from install of libstdc++47-4.7.2-2.11.i686 conflicts with file from package libstdc++-4.8.1-1.20.i686 [ 64s] exit ... 6 instances of Missing Patch File Errors look similar to: [ 12s] + exec rpmbuild --define '_srcdefattr (-,root,root)' --nosignature --target=i686-tizen-linux --define '_build_create_debug 1' -ba /home/abuild/rpmbuild/SOURCES/cross-armv5el-gcc47-icecream-backend.spec [ 12s] error: Bad source: /home/abuild/rpmbuild/SOURCES/0001-dir-version.patch: No such file or directory [ 12s] Building target platforms: i686-tizen-linux [ 12s] Building for target i686-tizen-linux I'm not sure that understand why there would ever be a patch file here--Isn't the goal to have everything in the original sources? 7 instances of some other file missing Errors like: [ 4s] reqesting http://download.tizen.org/releases/daily/tizen/ivi/latest/repos/ivi/ia32/packages/repodata/repomd.xml failed: 404 Not Found [ 4s] Couldn't open /home/phanchet/GBS-TIZEN-3.0M2/local/cache/0cca4ce1752580229c4256e2194fb1e7/repodata/repomd.xml: [ 4s] No such file or directory at /usr/lib/build/createrepomddeps line 436 a nd: [ 45s] libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE=1 -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DXTABLES_LIBDIR=\"/usr/lib/xtables\" -DXTABLES_INTERNAL -I../include -I../include -Wall -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wshadow -Wstrict-prototypes -Winline -pipe -O2 -g -m32 -march=i686 -mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -MT libipq.lo -MD -MP -MF .deps/libipq.Tpo -c libipq.c -fPIC -DPIC -o .libs/libipq.o [ 45s] In file included from libipq.c:34:0: [ 45s] ../include/libipq/libipq.h:33:43: fatal error: linux/netfilter_ipv4/ip_queue.h: No such file or directory [ 45s] compilation terminated. [ 45s] make[2]: *** [libipq.lo] Error 1 [ 45s] make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/iptables-1.4.14/libipq' [ 45s] make[1]: *** [all-recursive] Error 1 [ 45s] make[1]: Leaving directory `/home/abuild/rpmbuild/BUILD/iptables-1.4.14' [ 45s] make: *** [all] Error 2 [ 45s] error: Bad exit status from /var/tmp/rpm-tmp.k2HLdr (%build) and: [ 68s] + exec rpmbuild --define '_srcdefattr (-,root,root)' --nosignature --target=i686-tizen-linux --define '_build_create_debug 1' -ba /home/abuild/rpmbuild/SOURCES/python-rpm.spec [ 68s] error: File /home/abuild/rpmbuild/SOURCES/rpm-4.11.0.1.tar.bz2: No such file or directory [ 68s] Building target platforms: i686-tizen-linux [ 68s] Building for target i686-tizen-linux 2 instances of Nothing Provides [ 1s] nothing provides libcurl.so.4(CURL_OPENSSL_4) needed by cmake and [ 8s] nothing provides xorg-launch-helper 1 unique error Finally: [ 21s] now finalizing build dir... [ 21s] chroot: failed to run command `su': No such file or directory [ 21s] Error: TOPDIR empty Other Observations: I also thought I noticed several places where there were strong warnings in RPM build code as well as in the sources for the package being built-- I don't have specific references at the moment, but I'll note that there are so many "normal" errors being reported that it's hard to spot the true trouble spots that need attention. Analysis and Conclusions: We've taken pains to try to ensure that we started with a single cohesive set of sources, specifically those for the Aug M2 release of Tizen. At the bottom, everything is built with make files under the supervision of rpmbuild, with gbs (or obs) on top of that. Given the same sources, I really expect rpmbuild to produce the same result regardless of how it's started. ***IF*** we are starting with the same sources (remember, that was our intent at the top of this missive), then it's quite difficult to understand why we aren't able to replicate the successful build (on obs) of these packages. Looking at the errors themselves, all of the files referring to libstdc++ that built refer to the 4.7 version of the library while the files with errors seem to be trying to refer to the 4.8 version of the library. Patch files clearly have been removed without updating the corresponding spec files. File missing and nothing provides are also variations of the build meta-system being out of sync with itself. The point is that the errors we are seeing will always be fatal to the build, regardless of how it is initiated. So, I'm wondering what have I done wrong? The full failure logs are attached. I'm wondering if it's possible to review the success and failure logs from the obs build so I can compare with what I have here? TIA for your thoughts! Paul Hanchett ------------------- Infotainment Engineer MSX on behalf of Jaguar Land Rover One World Trade Center, 121 Southwest Salmon Street, 11th Floor, Portland, Oregon, 97204 Email: [email protected]<mailto:[email protected]> ------------------- Business Details: Jaguar Land Rover Limited Registered Office: Abbey Road, Whitley, Coventry CV3 4LF Registered in England No: 1672070 Intel Corporation NV/SA Kings Square, Veldkant 31 2550 Kontich RPM (Bruxelles) 0415.497.718. Citibank, Brussels, account 570/1031255/09 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
