It was <2014-12-03 śro 14:20>, when Patrick Ohly wrote: > On Wed, 2014-12-03 at 13:34 +0100, Łukasz Stelmach wrote: >> It was <2014-11-27 czw 14:26>, when Kévin THIERRY wrote: >>> On 11/27/2014 02:11 PM, Łukasz Stelmach wrote: >>>> It was <2014-11-27 czw 11:25>, when Kévin THIERRY wrote: >>>>> On 11/27/2014 11:05 AM, Łukasz Stelmach wrote: >>>>>> It was <2014-11-26 śro 16:02>, when Dominig ar Foll (Intel OTC) wrote: >>>>>>> The infra team has taken the time to document a model >>>>>>> proposition and would like to get all the feedback possible. >>>>>>> https://wiki.tizen.org/wiki/Tizen-Distro_Workflow >>>>>> Where can I find repositories with Yocto tools for Ubuntu 12.04 >>>>>> 14.04 and Debian 7? >>>>> Please follow this wiki page to build a Tizen image with Yocto: >>>>> https://wiki.tizen.org/wiki/Build_Tizen_with_Yocto_Project >>>> What is yocto equivalent of >>>> >>>> git clone git://git.tizen.org/platform/upstream/systemd.git >>>> cd systemd >>>> gbs build -A armv7l >>> cd poky >>> . ./oe-init-build-env >>> bitbake systemd >> >> --8<---------------cut here---------------start------------->8--- >> $ bitbake systemd >> Loading cache: 100% >> |###################################################################| ETA: >> 00:00:00 >> Loaded 1291 entries from dependency cache. >> ERROR: Nothing PROVIDES 'systemd' >> ERROR: systemd was skipped: 'systemd' not in DISTRO_FEATURES >> --8<---------------cut here---------------end--------------->8--- > > Set DISTRO = "tizen" in your local.conf and make sure that bblayers.conf > is set up according to > https://wiki.tizen.org/wiki/Build_Tizen_with_Yocto_Project > > This is a bit work in progress. In an older revision of meta-tizen, this > DISTRO_FEATURE was set when adding the meta-tizen-common-base layer. > > Now it gets set in tizen.conf from that same layer, which is what DISTRO > = "tizen" references.
I've got it. Apparently yoctoTizenUpdateSource took care. > However, I would like to caution against doing a 1:1 comparison at the > moment. What you'll immediately notice is that the command above is a > lot slower than the corresponding "gbs build" because it'll also build > all of the dependencies, both for tools needed to build and libs that > systemd is linking against. > > Bitbake has an feature addressing this (shared state = sstate) which we > will have to enable on tizen.org to get build times comparable to gbs. It should be possible to download dependencies if they are to be built using the same content (source, spec, distro configuration etc.). In Gentoo (which was an inspiration for open-embedded) it is possible to use rebuilt binary packages together with locally compiled software. > Another feature that would be nice to have is the PR service > (https://wiki.yoctoproject.org/wiki/PR_Service). It ensures that a > locally built package always has a higher revision number than the > corresponding package built by the core infrastructure. This is > something that gbs doesn't have, which is a nuisance when > replacing .rpms in an image (must force downgrades). There seem to be some hacks in GBS that give > Another area that'll need work is support for editing the source code. > In the "bitbake systemd" command above one cannot easily compile > modified code. Markus is already working on that. That makes bitbake an excellent poor-man's OBS but rather poor GBS. I've been thinking a bit more yocto/oe/bitbake could make Tizen development easier. OBS is here to stay. It is quite a good system for central building with a good web front-end. A lot of people has learnt it, both in Intel and in Samsung. GBS is acceptable as a tool to build packages locally. It uses the same back-end as OBS which makes it less likely for a developer to need to fix build-system dependent issues, a very important feature. There is a gap between those: OBS is hard to set-up ad-hoc and GBS can't rebuild large collections of interdependent packages. Bitbake/OE/Yocto (I can't tell which of their bits exactly) can fill the gap and make development, integration and maintenance of some base packages, which require a large number of packages to be rebuilt with every upgrade, a lot easier than fiddling with pre-release submits. MIC is a tool I like least. Partly because (which is not mic's fault) current image configuration is spread between IMHO too many packages and in the end one needs to extract ks files manually from an RPM. If Yocto/OE/BitBake is capable of using RPM from repositories in OBS (see p.1) for images, it may be used on Tizen servers as well as by developers which will bring the same consistency GBS and OBS provide today (p.2). It would be even cooler if it was possible to specify one-by-one packages I would like to rebuild for an image and which to download from a repository (e.g. tool-chains and stuff that don't go to the image). For Yocto to be really useful for Tizen (and I believe it can be) there need to be a capable and robust spec2bb converter (I feel it is easier to convert this way). The amount of native bb recipes required to build Tizen should be kept as little as possible to adhere to SPOT[1] principle. Yocto can replace MIC, can be used instead or next to GBS but it can't IMHO compete with OBS. [1] https://en.wikipedia.org/wiki/Single_Point_of_Truth -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgpXxFgH9jLL0.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
