I understand your due diligence. However you are pursuing methods that have never been used by the Tizen team, and which obviously don't work.
Even the GBS tools team management says that in theory GBS can rebuild all the Tizen source from git, it should not be used to do this on an ongoing basis. Truth is it has never been used to do this. The primary intent of GBS it to allow developers to rebuild a few packages that they are modifying and then use MIC or zypper to combine those modified packages with packages built by OBS on download.tizen.org to create a bootable image. There are developers and principle engineers who say GBS should never be used to rebuild all of Tizen from Source. We need to separate out two usages 1. Development phase work aligned with ongoing development on tizen.org (use GBS) 2. Product development based on a stable release archived on a separate build server isolated from ongoing updates to review.tizen.org/git. (use OBS, OBSlight or product developer's build server infrastructure). The August 29 preview of M2 (milestone 2 of Tizen IVI 3.0 development) was never meant to be a stable product release. It was meant to be a more stable (than daily builds) monthly preview. Here are some of the things going on with the Tizen build infrastructure that makes your attempts to rebuild August 29 using GBS from git repositories particularly difficult. 1. GBS assumes you are building with current tool sets against current git repositories. It does not preserve or archive a development tools root image to match old builds. 2. The August 29 preview was built from an OBS project based on git tree snapshot taken on August 22, with select patches added over the following 7 days. So the full Tizen git repos on Aug 29 were not compatible with the August 29 Tizen IVI preview. This was our 1 week freeze to stabilize (isolate from ongoing development) and fix a few critical bugs. 3. There was no tag/branch of the Aug 29 Tizen IVI preview because it is not a "Release" or even an RC for a major release. When we get to a major release freeze like 3.0 RC, we will tag and branch the code to provide a sustainable branch for future product development 4. Around August 29 the Tizen tools infrastructure had a major update with new versions of compiler, core libraries (glib, stdlib) etc. This caused turbulence that broke parts of the build for several days. Bottom line: 1) the August 29 Tizen IVI preview cannot be built from August 29 git repos. 2) GBS does not provide backward compatibility by archiving the tools infrastructure on a daily basis such that you can use the same tools and core libraries to build the August 29 image that were originally used to build that image. The quickest way to get the same sources used in the Tizen IVI Aug 29 preview is to use the source RPMs. How to reproduce the correct host development tools environment is well beyond my expertise, but it might be done by using the Tizen IVI Aug 29 Tizen image as your development host. Establishing a build server infrastructure to rebuild all tizen source code on a regular basis requires a substantial investment only justified by product development plans based on a specific release. On going development of Tizen and Tizen aligned services, middleware and even core apps is best pursued by working with the current git and download repos using GBS for local builds of a few modified packages. Regards Joel From: Hanchett, Paul [mailto:[email protected]] Sent: Thursday, September 12, 2013 11:22 AM To: Clark, Joel Cc: [email protected] Subject: Re: [Tizen General] Why not use tags to mark releases rather than the manifest file? Joel-- This is all part of corporate due diligence and risk management-- making sure that you have what you need in order to recreate what you are dependent on. When I was at McAfee, one of the regular QA steps was to do a final build of the product and compare it with what had been QA'ed. Think of it as "Trust, but Verify." :-) Paul 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 On Thu, Sep 12, 2013 at 11:06 AM, Clark, Joel <[email protected]<mailto:[email protected]>> wrote: Wouldn't it be easier just to download the source RPMs that are archived with the particularly release? http://download.tizen.org/releases/milestone/tizen/ivi/tizen_20130829.9/repos/ivi/source/ Rather than trying to rebuild stuff from the git repos that have already been updated with new patches before we even finish building the release much less verifying its good enough to actually release. Regards Joel From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Hanchett, Paul Sent: Thursday, September 12, 2013 11:00 AM To: [email protected]<mailto:[email protected]> Subject: [Tizen General] Why not use tags to mark releases rather than the manifest file? Why not use tags to mark a particular release, rather than the object ID in the manifest file? I see several advantages: * You get a single value that can be handed to gbs/obs to pull all of the packages as of a particular point in time; new commits have no impact on the git tag (unlike the branches we use now.) In fact, you might not even need manifest files........ * Now, it becomes dead easy to *see* in each repository the version that was actually released. Placing tags for other significant events makes those visible in every repository. I'm sure there are other advantages. Is there a down side? (I'm relatively new to git...) Thanks, 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
_______________________________________________ General mailing list [email protected] https://lists.tizen.org/listinfo/general
