* hello... @ 2007-10-04 10:41 Tobias Pflug 2007-10-04 11:18 ` hello Michael Krelin 0 siblings, 1 reply; 34+ messages in thread From: Tobias Pflug @ 2007-10-04 10:41 UTC (permalink / raw) To: openembedded-devel hey.. I just wanted to say hi to everyone on this list. I recently started working with OpenEmbedded. I'm using it at work for an embedded solution using the compulab boards. So far I am mostly enjoying the "openembedded experience".. The documenation could be a bit better and less scattered over different places but well.. noone loves writing documentation. But I have received good and friendly support from the #oe irc channel. The next point will perhaps not make me many friends on this list, but I am not exactly too fond of monotone. I for one would prefer if openembedded used git. Mostly because it is *so* much faster. My machine is fairly decent I would say and still the usage experience isn't that great. (`mtn status` = zZzz :) anyway, I look forward to using OE more and hopefully also contributing to it. best regards, Tobi ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hello... 2007-10-04 10:41 hello Tobias Pflug @ 2007-10-04 11:18 ` Michael Krelin 2007-10-04 12:40 ` hello Holger Freyther 0 siblings, 1 reply; 34+ messages in thread From: Michael Krelin @ 2007-10-04 11:18 UTC (permalink / raw) To: openembedded-devel > The next point will perhaps not make me many friends on this list, but > I am not exactly too fond of monotone. I for one would prefer if > openembedded used git. Mostly because it is *so* much faster. My machine > is fairly decent I would say and still the usage experience isn't that > great. (`mtn status` = zZzz :) So would I (and not only for performance reasons), but I doubt it's going to happen anytime soon ;-) Love, H ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hello... 2007-10-04 11:18 ` hello Michael Krelin @ 2007-10-04 12:40 ` Holger Freyther 2007-10-04 12:55 ` monotone/git (was hello...) Tobias Pflug 2007-10-04 13:19 ` hello Michael Krelin 0 siblings, 2 replies; 34+ messages in thread From: Holger Freyther @ 2007-10-04 12:40 UTC (permalink / raw) To: openembedded-devel Am 04.10.2007 um 13:18 schrieb Michael Krelin: >> The next point will perhaps not make me many friends on this list, >> but >> I am not exactly too fond of monotone. I for one would prefer if >> openembedded used git. Mostly because it is *so* much faster. My >> machine >> is fairly decent I would say and still the usage experience isn't >> that >> great. (`mtn status` = zZzz :) > > So would I (and not only for performance reasons), but I doubt it's > going to happen anytime soon ;-) Hi, If someone can host my mtn2git script and a git tree we can have a git mirror almost immediately. But yes I think there are some good reasons to stay with monotone as primary system. z. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 12:40 ` hello Holger Freyther @ 2007-10-04 12:55 ` Tobias Pflug 2007-10-04 13:27 ` Holger Freyther 2007-10-04 13:30 ` Michael Krelin 2007-10-04 13:19 ` hello Michael Krelin 1 sibling, 2 replies; 34+ messages in thread From: Tobias Pflug @ 2007-10-04 12:55 UTC (permalink / raw) To: openembedded-devel On Thu, 2007-10-04 at 14:40 +0200, Holger Freyther wrote: > Am 04.10.2007 um 13:18 schrieb Michael Krelin: > > Hi, > > If someone can host my mtn2git script and a git tree we can have a > git mirror almost immediately. But yes I think there are some good > reasons to stay with monotone as primary system. > > > z. Well luckily I am not an ignorant git-fanboy :) Could you shortly point out to me the reasons why you think monotone is favorable over git for use with openembedded ? I will admit right away that my limitation with SCMs in large projects is more than limited. So i can only speak of my user experience with git vs my experience with monotone and i prefer the first. thanks. -Tobi ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 12:55 ` monotone/git (was hello...) Tobias Pflug @ 2007-10-04 13:27 ` Holger Freyther 2007-10-04 13:50 ` Darcy Watkins 2007-10-04 13:51 ` Michael Krelin 2007-10-04 13:30 ` Michael Krelin 1 sibling, 2 replies; 34+ messages in thread From: Holger Freyther @ 2007-10-04 13:27 UTC (permalink / raw) To: openembedded-devel Am 04.10.2007 um 14:55 schrieb Tobias Pflug: > Well luckily I am not an ignorant git-fanboy :) Could you shortly > point > out to me the reasons why you think monotone is favorable over git for > use with openembedded ? I will admit right away that my limitation > with > SCMs in large projects is more than limited. So i can only speak of > my user experience with git vs my experience with monotone and i > prefer > the first. Hi, this will be my only to this topic but I see that as following: git: pros: + Speed + Momentum + Merging cons: - Incompats with other versions - repacking (even if probably all known races are fixed) - shell mess with bashism and GNUism - still complicated to use - Does not track directories mtn: cons: - Speed on rev pulling (I think mtn ls and status, diff is quite fast) - we can not easily merge the dreambox branch (this is why I wrote mtn2git) pros: + trust (I don't feel like remembering the latest over night) + awesome manual + trusting the code base (git is catching up, Linus is a god... but...) + certs attachable to revs + attributes and other testresults are attachable to files and it is on my todolist to use them + tracks directories + portable The last three/four reasons are the one why I would propose to stay with mtn as the main repository. I'm also working on a git2mtn script (after having merged the dreambox branch) which could make git a (semi) supported system for OE (if someone will host it). z. PS: I almost exclusively use git-svn for my work on WebKit, specially for git-reabse... ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 13:27 ` Holger Freyther @ 2007-10-04 13:50 ` Darcy Watkins 2007-10-04 13:52 ` Michael Krelin 2007-10-04 18:02 ` monotone/git (was hello...) Richard Purdie 2007-10-04 13:51 ` Michael Krelin 1 sibling, 2 replies; 34+ messages in thread From: Darcy Watkins @ 2007-10-04 13:50 UTC (permalink / raw) To: openembedded-devel Hello, If there is actually any real serious consideration of changing the source control system, you should also consider mercurial as well as git versus monotone. At least consider adding a recipe to fetch package source from a mercurial based upstream source. Regards, Darcy ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 13:50 ` Darcy Watkins @ 2007-10-04 13:52 ` Michael Krelin 2007-10-05 6:28 ` oe for two target boards at the same time Alex 2007-10-04 18:02 ` monotone/git (was hello...) Richard Purdie 1 sibling, 1 reply; 34+ messages in thread From: Michael Krelin @ 2007-10-04 13:52 UTC (permalink / raw) To: openembedded-devel > Hello, > > If there is actually any real serious consideration of changing the > source control system, you should also consider mercurial as well as git > versus monotone. At least consider adding a recipe to fetch package > source from a mercurial based upstream source. I think this is unrelated and if there are packages that require it, it should be done anyway. Love, H ^ permalink raw reply [flat|nested] 34+ messages in thread
* oe for two target boards at the same time 2007-10-04 13:52 ` Michael Krelin @ 2007-10-05 6:28 ` Alex 2007-10-05 13:57 ` Cliff Brake 0 siblings, 1 reply; 34+ messages in thread From: Alex @ 2007-10-05 6:28 UTC (permalink / raw) To: openembedded-devel Hi all How do I setup my directory structure to use oe for two target boards. I have an AVR32 board and an AT91 board and would like to use oe for both of them with at less dublicated software as possible. Thanks Alex ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: oe for two target boards at the same time 2007-10-05 6:28 ` oe for two target boards at the same time Alex @ 2007-10-05 13:57 ` Cliff Brake 2007-10-05 15:47 ` Khem Raj ` (3 more replies) 0 siblings, 4 replies; 34+ messages in thread From: Cliff Brake @ 2007-10-05 13:57 UTC (permalink / raw) To: openembedded-devel On 10/5/07, Alex <mailinglist@miromico.ch> wrote: > Hi all > > How do I setup my directory structure to use oe for two target boards. > > I have an AVR32 board and an AT91 board and would like to use oe for > both of them with at less dublicated software as possible. As these are different architectures, I don't think you can use multimachine. What I typically do is just set up a system where I share a common overlay (bbcollections), the openembedded directory, and downloads directory. The nslu2 master makefile what I started with, but there are other ways. Soft links are used to link the common directories. EG: openembedded openembedded.custom (bb collections overlay) bitbake downloads projectA openembedded.custom -> ../openembedded.custom openembedded -> ../openembedded bitbake -> ../bitbake downloads -> ../downloads tmp conf projectB openembedded.custom -> ../openembedded.custom openembedded -> ../openembedded bitbake -> ../bitbake downloads -> ../downloads tmp conf I'd be interested in hearing how others set up their build directory. Thanks, Cliff -- ======================= Cliff Brake http://bec-systems.com ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: oe for two target boards at the same time 2007-10-05 13:57 ` Cliff Brake @ 2007-10-05 15:47 ` Khem Raj 2007-10-06 8:19 ` Koen Kooi ` (2 subsequent siblings) 3 siblings, 0 replies; 34+ messages in thread From: Khem Raj @ 2007-10-05 15:47 UTC (permalink / raw) To: openembedded-devel I generally use a separate tmp directory for each machine and common sources. This has worked well for me so far. -Khem On 10/5/07, Cliff Brake <cliff.brake@gmail.com> wrote: > On 10/5/07, Alex <mailinglist@miromico.ch> wrote: > > Hi all > > > > How do I setup my directory structure to use oe for two target boards. > > > > I have an AVR32 board and an AT91 board and would like to use oe for > > both of them with at less dublicated software as possible. > > As these are different architectures, I don't think you can use > multimachine. What I typically do is just set up a system where I > share a common overlay (bbcollections), the openembedded directory, > and downloads directory. The nslu2 master makefile what I started > with, but there are other ways. Soft links are used to link the > common directories. EG: > > openembedded > openembedded.custom (bb collections overlay) > bitbake > downloads > projectA > openembedded.custom -> ../openembedded.custom > openembedded -> ../openembedded > bitbake -> ../bitbake > downloads -> ../downloads > tmp > conf > projectB > openembedded.custom -> ../openembedded.custom > openembedded -> ../openembedded > bitbake -> ../bitbake > downloads -> ../downloads > tmp > conf > > I'd be interested in hearing how others set up their build directory. > > Thanks, > Cliff > > -- > ======================= > Cliff Brake > http://bec-systems.com > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: oe for two target boards at the same time 2007-10-05 13:57 ` Cliff Brake 2007-10-05 15:47 ` Khem Raj @ 2007-10-06 8:19 ` Koen Kooi 2007-10-06 11:39 ` Marcin Juszkiewicz 2007-10-08 20:20 ` Cliff Brake 3 siblings, 0 replies; 34+ messages in thread From: Koen Kooi @ 2007-10-06 8:19 UTC (permalink / raw) To: Using the OpenEmbedded metadata to build Distributions -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cliff Brake schreef: > On 10/5/07, Alex <mailinglist@miromico.ch> wrote: >> Hi all >> >> How do I setup my directory structure to use oe for two target boards. >> >> I have an AVR32 board and an AT91 board and would like to use oe for >> both of them with at less dublicated software as possible. > > As these are different architectures, I don't think you can use > multimachine. Multimachine works fine for things like that, except that we are *still* waiting for an OK to merge the avr32 stuff into .dev regards, Koen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHB0UbMkyGM64RGpERAgalAJ4j+ouRvC4msp8DZImB06lYyqvJtgCbBBEe gVcJQX+e3nHCHBA2dQ0xfOY= =qvpO -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: oe for two target boards at the same time 2007-10-05 13:57 ` Cliff Brake 2007-10-05 15:47 ` Khem Raj 2007-10-06 8:19 ` Koen Kooi @ 2007-10-06 11:39 ` Marcin Juszkiewicz 2007-10-08 20:20 ` Cliff Brake 3 siblings, 0 replies; 34+ messages in thread From: Marcin Juszkiewicz @ 2007-10-06 11:39 UTC (permalink / raw) To: openembedded-devel Dnia piątek, 5 października 2007, Cliff Brake napisał: > On 10/5/07, Alex <mailinglist@miromico.ch> wrote: > > How do I setup my directory structure to use oe for two target > > boards. > > I have an AVR32 board and an AT91 board and would like to use oe for > > both of them with at less dublicated software as possible. > As these are different architectures, I don't think you can use > multimachine. You can use multimachine even when TARGET_ARCH differ - only *-native utils will be the same - all cross tools will be built for both targets. > What I typically do is just set up a system where I share a common > overlay (bbcollections), the openembedded directory, > and downloads directory. > I'd be interested in hearing how others set up their build directory. http://blog.haerwu.biz/2006/11/22/my-openembedded-environment-ii/ is how I have it configured. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: oe for two target boards at the same time 2007-10-05 13:57 ` Cliff Brake ` (2 preceding siblings ...) 2007-10-06 11:39 ` Marcin Juszkiewicz @ 2007-10-08 20:20 ` Cliff Brake 2007-10-09 8:28 ` Koen Kooi 2007-10-09 16:48 ` Paul Sokolovsky 3 siblings, 2 replies; 34+ messages in thread From: Cliff Brake @ 2007-10-08 20:20 UTC (permalink / raw) To: openembedded-devel On 10/5/07, Cliff Brake <cliff.brake@gmail.com> wrote: > On 10/5/07, Alex <mailinglist@miromico.ch> wrote: > > Hi all > > > > How do I setup my directory structure to use oe for two target boards. > > > > I have an AVR32 board and an AT91 board and would like to use oe for > > both of them with at less dublicated software as possible. > I'd be interested in hearing how others set up their build directory. After studying Marcin's build setup, and Koen's autobuilder script, I've come up with the following which is very similiar to Marcin's setup. My needs are: - track several machines and distros, and possibly in the future different OE trees, etc - easily to automatically produce time-stamped snapshot builds (not done yet) - easy for me to replicate on other machines - easy for customers to replicate on other machines With the multimachine, you typically need one build directory per distro, so the following is what I ended up with: |-- Makefile `-- oe | `-- custom (bbcollections overlay) | `-- org.openembedded.dev `-- bitbake `-- downloads `-- build |-- angstrom-2007.1 | `-- conf | |-- local.conf | |-- auto.conf | `-- site.conf -> ../../conf/site.conf |-- angstrom-2008.1 | `-- conf | |-- local.conf | |-- auto.conf | `-- site.conf -> ../../conf/site.conf |-- conf | `-- site.conf `-- openmoko `-- conf |-- local.conf |-- auto.conf `-- site.conf -> ../../conf/site.conf There is a common site.conf file that contains settings for my build machine. local.conf contains the DISTRO variable, and thats about it. auto.conf contains MACHINE and uclibc settings and is changed between builds. The downside of multimachine is you need to reparse the OE directory every time you change machine, but the benefit of sharing tmp directories for a bunch of machines in a distro more than makes up for that. Cliff -- ======================= Cliff Brake http://bec-systems.com ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: oe for two target boards at the same time 2007-10-08 20:20 ` Cliff Brake @ 2007-10-09 8:28 ` Koen Kooi 2007-10-09 9:02 ` pHilipp Zabel 2007-10-09 16:48 ` Paul Sokolovsky 1 sibling, 1 reply; 34+ messages in thread From: Koen Kooi @ 2007-10-09 8:28 UTC (permalink / raw) To: openembedded-devel Quoting Cliff Brake <cliff.brake@gmail.com>: > On 10/5/07, Cliff Brake <cliff.brake@gmail.com> wrote: > > On 10/5/07, Alex <mailinglist@miromico.ch> wrote: > > > Hi all > > > > > > How do I setup my directory structure to use oe for two target boards. > > > > > > I have an AVR32 board and an AT91 board and would like to use oe for > > > both of them with at less dublicated software as possible. > > > I'd be interested in hearing how others set up their build directory. > > After studying Marcin's build setup, and Koen's autobuilder script, > I've come up with the following which is very similiar to Marcin's > setup. My needs are: > > - track several machines and distros, and possibly in the future > different OE trees, etc > - easily to automatically produce time-stamped snapshot builds (not done yet) > - easy for me to replicate on other machines > - easy for customers to replicate on other machines > > With the multimachine, you typically need one build directory per > distro, so the following is what I ended up with: If you only need to build one distro version you can do: TMPDIR = "/build/tmp/${DISTRO}" in local.conf > The downside of multimachine is you need to reparse the OE directory > every time you change machine, but the benefit of sharing tmp > directories for a bunch of machines in a distro more than makes up for > that. If you already built binutils you can remove MACHINE=<foo> from conf files and set it in env, e.g. : MACHINE=c7x0 bitbake mono ; MACHINE=fic-gta01 bitbake mono that saves you a complete reparse. regards, Koen ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: oe for two target boards at the same time 2007-10-09 8:28 ` Koen Kooi @ 2007-10-09 9:02 ` pHilipp Zabel 2007-10-09 10:36 ` Richard Purdie 0 siblings, 1 reply; 34+ messages in thread From: pHilipp Zabel @ 2007-10-09 9:02 UTC (permalink / raw) To: openembedded-devel; +Cc: openembedded-devel On 10/9/07, Koen Kooi <k.kooi@student.utwente.nl> wrote: > Quoting Cliff Brake <cliff.brake@gmail.com>: > > > On 10/5/07, Cliff Brake <cliff.brake@gmail.com> wrote: > > > On 10/5/07, Alex <mailinglist@miromico.ch> wrote: > > > > Hi all > > > > > > > > How do I setup my directory structure to use oe for two target boards. > > > > > > > > I have an AVR32 board and an AT91 board and would like to use oe for > > > > both of them with at less dublicated software as possible. > > > > > I'd be interested in hearing how others set up their build directory. > > > > After studying Marcin's build setup, and Koen's autobuilder script, > > I've come up with the following which is very similiar to Marcin's > > setup. My needs are: > > > > - track several machines and distros, and possibly in the future > > different OE trees, etc > > - easily to automatically produce time-stamped snapshot builds (not done yet) > > - easy for me to replicate on other machines > > - easy for customers to replicate on other machines > > > > With the multimachine, you typically need one build directory per > > distro, so the following is what I ended up with: > > If you only need to build one distro version you can do: > > TMPDIR = "/build/tmp/${DISTRO}" > > in local.conf > > > > The downside of multimachine is you need to reparse the OE directory > > every time you change machine, but the benefit of sharing tmp > > directories for a bunch of machines in a distro more than makes up for > > that. > > If you already built binutils you can remove MACHINE=<foo> from conf files and > set it in env, e.g. : > > MACHINE=c7x0 bitbake mono ; MACHINE=fic-gta01 bitbake mono > > that saves you a complete reparse. Isn't the binutils MACHINE environment variable issue fixed by now? I only just noticed that I don't know because I have MACHINE?=magician somewhere and always seem to do the first build without the MACHINE envvar set... regards Philipp ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: oe for two target boards at the same time 2007-10-09 9:02 ` pHilipp Zabel @ 2007-10-09 10:36 ` Richard Purdie 2007-10-09 11:18 ` Graeme Gregory 2007-10-09 16:52 ` Paul Sokolovsky 0 siblings, 2 replies; 34+ messages in thread From: Richard Purdie @ 2007-10-09 10:36 UTC (permalink / raw) To: openembedded-devel On Tue, 2007-10-09 at 11:02 +0200, pHilipp Zabel wrote: > On 10/9/07, Koen Kooi <k.kooi@student.utwente.nl> wrote: > > If you already built binutils you can remove MACHINE=<foo> from conf files and > > set it in env, e.g. : > > > > MACHINE=c7x0 bitbake mono ; MACHINE=fic-gta01 bitbake mono > > > > that saves you a complete reparse. > > Isn't the binutils MACHINE environment variable issue fixed by now? > I only just noticed that I don't know because I have MACHINE?=magician > somewhere and always seem to do the first build without the MACHINE > envvar set... The issue should be fixed. I regularly make builds with a MACHINE ?= entry but with MACHINE set in the environment too and it all seems to work. People keep telling me there is a problem but I've not seen any reproducible test case... Cheers, Richard ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: oe for two target boards at the same time 2007-10-09 10:36 ` Richard Purdie @ 2007-10-09 11:18 ` Graeme Gregory 2007-10-09 11:49 ` Graeme Gregory 2007-10-09 16:52 ` Paul Sokolovsky 1 sibling, 1 reply; 34+ messages in thread From: Graeme Gregory @ 2007-10-09 11:18 UTC (permalink / raw) To: openembedded-devel On Tue, 09 Oct 2007 12:36:22 +0200 Richard Purdie <rpurdie@rpsys.net> wrote: > The issue should be fixed. I regularly make builds with a MACHINE ?= > entry but with MACHINE set in the environment too and it all seems to > work. > > People keep telling me there is a problem but I've not seen any > reproducible test case... > NOTE: package binutils-cross-2.18-r0: task do_populate_staging: completed looks fixed to me, I never used to be able to do this. Graeme ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: oe for two target boards at the same time 2007-10-09 11:18 ` Graeme Gregory @ 2007-10-09 11:49 ` Graeme Gregory 0 siblings, 0 replies; 34+ messages in thread From: Graeme Gregory @ 2007-10-09 11:49 UTC (permalink / raw) To: openembedded-devel On Tue, 9 Oct 2007 13:18:12 +0200 Graeme Gregory <dp@xora.org.uk> wrote: > On Tue, 09 Oct 2007 12:36:22 +0200 > Richard Purdie <rpurdie@rpsys.net> wrote: > > The issue should be fixed. I regularly make builds with a MACHINE ?= > > entry but with MACHINE set in the environment too and it all seems > > to work. > > > > People keep telling me there is a problem but I've not seen any > > reproducible test case... > > > > NOTE: package binutils-cross-2.18-r0: task do_populate_staging: > completed > > looks fixed to me, I never used to be able to do this. > Spoke too soon checking for libc-friendly stddef.h... yes checking whether we need to use -P to assemble .S files... no checking whether .text pseudo-op must be used... yes checking for assembler global-symbol directive... .globl checking for .set assembler directive... no checking for assembler .type directive prefix... % checking for .symver assembler directive... yes checking for ld --version-script... no *** WARNING: You should not compile GNU libc without versioning. Not using *** versioning will introduce incompatibilities so that old binaries *** will not run anymore. *** For versioning you need recent binutils (binutils-2.8.1.0.23 or newer). checking for .previous assembler directive... yes checking for .protected and .hidden assembler directive... yes checking whether __attribute__((visibility())) is supported... yes checking for broken __attribute__((visibility()))... no checking for broken __attribute__((alias()))... no checking whether to put _rtld_local into .sdata section... no checking for arm-angstrom-linux-gnueabi-readelf... arm-angstrom-linux-gnueabi-re adelf checking for .preinit_array/.init_array/.fini_array support... no configure: error: Need linker with .init_array/.fini_array support. FATAL: oe_runconf failed This is what happens if MACHINE=spitz bitbake angstrom-devel-image Graeme ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: oe for two target boards at the same time 2007-10-09 10:36 ` Richard Purdie 2007-10-09 11:18 ` Graeme Gregory @ 2007-10-09 16:52 ` Paul Sokolovsky 1 sibling, 0 replies; 34+ messages in thread From: Paul Sokolovsky @ 2007-10-09 16:52 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-devel Hello Richard, Tuesday, October 9, 2007, 1:36:22 PM, you wrote: > On Tue, 2007-10-09 at 11:02 +0200, pHilipp Zabel wrote: >> On 10/9/07, Koen Kooi <k.kooi@student.utwente.nl> wrote: >> > If you already built binutils you can remove MACHINE=<foo> from conf files and >> > set it in env, e.g. : >> > >> > MACHINE=c7x0 bitbake mono ; MACHINE=fic-gta01 bitbake mono >> > >> > that saves you a complete reparse. >> >> Isn't the binutils MACHINE environment variable issue fixed by now? >> I only just noticed that I don't know because I have MACHINE?=magician >> somewhere and always seem to do the first build without the MACHINE >> envvar set... > The issue should be fixed. I regularly make builds with a MACHINE ?= > entry but with MACHINE set in the environment too and it all seems to > work. > People keep telling me there is a problem but I've not seen any > reproducible test case... Thanks for bringing this up. Not yet, not yet. Following patch was produced to fix another manifestation of the issue, hopefully forever: Index: lib/bb/data.py =================================================================== --- lib/bb/data.py (revision 974) +++ lib/bb/data.py (working copy) @@ -370,18 +370,19 @@ if type(val) is not types.StringType: return 0 - if getVarFlag(var, 'matchesenv', d): - return 0 - if (var.find("-") != -1 or var.find(".") != -1 or var.find('{') != -1 or var.find('}') != -1 or var.find('+') != -1) and not all: return 0 varExpanded = expand(var, d) + # Unexporting is the highest priority if unexport: o.write('unset %s\n' % varExpanded) return 1 + if getVarFlag(var, 'matchesenv', d): + return 0 + val.rstrip() if not val: return 0 The idea is simple: if a var is marked as unexported, then it should be unset unconditionally regardless of any other circumstances ;-). So, I hit this issue on a RedHat-based system (FC5). Otherwise, it seemed to have worked on Debian/Gentoo systems. > Cheers, > Richard -- Best regards, Paul mailto:pmiscml@gmail.com ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: oe for two target boards at the same time 2007-10-08 20:20 ` Cliff Brake 2007-10-09 8:28 ` Koen Kooi @ 2007-10-09 16:48 ` Paul Sokolovsky 1 sibling, 0 replies; 34+ messages in thread From: Paul Sokolovsky @ 2007-10-09 16:48 UTC (permalink / raw) To: Cliff Brake Hello Cliff, Monday, October 8, 2007, 11:20:14 PM, you wrote: > On 10/5/07, Cliff Brake <cliff.brake@gmail.com> wrote: >> On 10/5/07, Alex <mailinglist@miromico.ch> wrote: >> > Hi all >> > >> > How do I setup my directory structure to use oe for two target boards. >> > >> > I have an AVR32 board and an AT91 board and would like to use oe for >> > both of them with at less dublicated software as possible. >> I'd be interested in hearing how others set up their build directory. > After studying Marcin's build setup, and Koen's autobuilder script, Is there a reason why this script is not in contrib/ in OE tree? [] > - easily to automatically produce time-stamped snapshot builds (not done yet) I wonder if someone would ever bother to produce *revision*-stamped snapshots. Well, actually I wonder if in one sweet day in distant years OE would have that as default. Because it's of course the only reasonable way to ensure QAbility of snapshots. Yep, mtn's revisions are ugly, but that's price of "distributed SCM" magic, right? Plus, they can be trimmed to sane length. [] -- Best regards, Paul mailto:pmiscml@gmail.com ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 13:50 ` Darcy Watkins 2007-10-04 13:52 ` Michael Krelin @ 2007-10-04 18:02 ` Richard Purdie 1 sibling, 0 replies; 34+ messages in thread From: Richard Purdie @ 2007-10-04 18:02 UTC (permalink / raw) To: openembedded-devel On Thu, 2007-10-04 at 06:50 -0700, Darcy Watkins wrote: > If there is actually any real serious consideration of changing the > source control system, you should also consider mercurial as well as git > versus monotone. At least consider adding a recipe to fetch package > source from a mercurial based upstream source. FWIW, the basics of a mercurial fetcher were added to bitbake trunk recently. Regards, Richard ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 13:27 ` Holger Freyther 2007-10-04 13:50 ` Darcy Watkins @ 2007-10-04 13:51 ` Michael Krelin 1 sibling, 0 replies; 34+ messages in thread From: Michael Krelin @ 2007-10-04 13:51 UTC (permalink / raw) To: openembedded-devel > this will be my only to this topic but I see that as following: Why won't you clarify your points? > git: > cons: > - Incompats with other versions What do you mean? > - repacking (even if probably all known races are fixed) That's not a contra if we compare with monotone. > - shell mess with bashism and GNUism Very true and, likely to be a show-stopper, anyway. > - still complicated to use Well, if you use the monotone subset of git, it's not ;-) > - Does not track directories Is it a problem with OE? > mtn: > cons: > - Speed on rev pulling (I think mtn ls and status, diff is quite fast) > - we can not easily merge the dreambox branch (this is why I wrote > mtn2git) Aha, now I know the script exists :-) > pros: > + trust (I don't feel like remembering the latest over night) Can you elaborate on the expression in parentheses? > + awesome manual I wouldn't call it awesome when it goes beyond trivialities, but I don't think it's a problem with either SCM. > + trusting the code base (git is catching up, Linus is a god... > but...) Well, OE relies on git codebase indirectly anyway ;-) > + certs attachable to revs > + attributes and other testresults are attachable to files and it > is on my todolist to use them > + tracks directories > + portable > > > The last three/four reasons are the one why I would propose to stay > with mtn as the main repository. I'm also working on a git2mtn script > (after having merged the dreambox branch) which could make git a > (semi) supported system for OE (if someone will host it). The bottom line is - we're not going to move anytime soon. And I agree it makes sense. I'm yet to see what are these attributes and other testresults attachable to files (sounds interesting), but I'm a bit afraid of your idea of (ab)using it, since that may make us get stuck with mtn in the future no matter what. Love, H ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 12:55 ` monotone/git (was hello...) Tobias Pflug 2007-10-04 13:27 ` Holger Freyther @ 2007-10-04 13:30 ` Michael Krelin 2007-10-04 18:36 ` Chris Larson 1 sibling, 1 reply; 34+ messages in thread From: Michael Krelin @ 2007-10-04 13:30 UTC (permalink / raw) To: openembedded-devel > Well luckily I am not an ignorant git-fanboy :) Could you shortly point > out to me the reasons why you think monotone is favorable over git for > use with openembedded ? I will admit right away that my limitation with > SCMs in large projects is more than limited. So i can only speak of > my user experience with git vs my experience with monotone and i prefer > the first. Well, 1st - OE folks are used to monotone now. That's primary reason. The second primary reason is that I know of some developers who seem to dislike git. And if we're talking about technical reason, one I can think of is that there's no non-ssh transport allowing push, which complicates administration of our "central" repository. Basically, monotone is not really used as a DSCM in OE, it's just a somewhat centralized SCM which allows merges as well as forks. Personally, I think the lack of tools like gitk makes mtn history almost opaque which gets even more opaque and unreadable due to the lack of features like rebase. I do think also that potential corporate users of OE would appreciate git (the mirror would mostly solve this, though) as *I* think it's much easier with git to maintain own branch while picking the important changes from our tree (contributing back will be more complicated, though). The above is my personal opinion and I have to admit I may miss something about monotone, since, although I've had no problems using it both ways, I wouldn't say I'm a monotonic guru. Love, H ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 13:30 ` Michael Krelin @ 2007-10-04 18:36 ` Chris Larson 2007-10-04 18:49 ` Tim Bird 2007-10-04 19:08 ` Michael Krelin 0 siblings, 2 replies; 34+ messages in thread From: Chris Larson @ 2007-10-04 18:36 UTC (permalink / raw) To: openembedded-devel On 10/4/07, Michael Krelin <hacker@klever.net> wrote: > > Well luckily I am not an ignorant git-fanboy :) Could you shortly point > > out to me the reasons why you think monotone is favorable over git for > > use with openembedded ? I will admit right away that my limitation with > > SCMs in large projects is more than limited. So i can only speak of > > my user experience with git vs my experience with monotone and i prefer > > the first. > > Well, 1st - OE folks are used to monotone now. That's primary reason. > The second primary reason is that I know of some developers who seem to > dislike git. And if we're talking about technical reason, one I can > think of is that there's no non-ssh transport allowing push, which > complicates administration of our "central" repository. That's not correct. You can push to a git repository over http/webdav to an apache2 server. -- Chris Larson - clarson at kergoth dot com Dedicated Engineer - MontaVista - clarson at mvista dot com Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 18:36 ` Chris Larson @ 2007-10-04 18:49 ` Tim Bird 2007-10-04 18:57 ` Chris Larson 2007-10-04 19:08 ` Michael Krelin 1 sibling, 1 reply; 34+ messages in thread From: Tim Bird @ 2007-10-04 18:49 UTC (permalink / raw) To: openembedded-devel Chris Larson wrote: > On 10/4/07, Michael Krelin <hacker@klever.net> wrote: >>> Well luckily I am not an ignorant git-fanboy :) Could you shortly point >>> out to me the reasons why you think monotone is favorable over git for >>> use with openembedded ? I will admit right away that my limitation with >>> SCMs in large projects is more than limited. So i can only speak of >>> my user experience with git vs my experience with monotone and i prefer >>> the first. >> Well, 1st - OE folks are used to monotone now. That's primary reason. >> The second primary reason is that I know of some developers who seem to >> dislike git. And if we're talking about technical reason, one I can >> think of is that there's no non-ssh transport allowing push, which >> complicates administration of our "central" repository. > > That's not correct. You can push to a git repository over http/webdav > to an apache2 server. Theoretically. My experience is that it often fails, at least with the kernel. But maybe this is just a git-tree maintenance issue for the kernel devs. Chris is correct, however, that the feature is present in git. -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America ============================= ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 18:49 ` Tim Bird @ 2007-10-04 18:57 ` Chris Larson 2007-10-04 19:11 ` Michael Krelin 0 siblings, 1 reply; 34+ messages in thread From: Chris Larson @ 2007-10-04 18:57 UTC (permalink / raw) To: openembedded-devel On 10/4/07, Tim Bird <tim.bird@am.sony.com> wrote: > Chris Larson wrote: > > On 10/4/07, Michael Krelin <hacker@klever.net> wrote: > >>> Well luckily I am not an ignorant git-fanboy :) Could you shortly point > >>> out to me the reasons why you think monotone is favorable over git for > >>> use with openembedded ? I will admit right away that my limitation with > >>> SCMs in large projects is more than limited. So i can only speak of > >>> my user experience with git vs my experience with monotone and i prefer > >>> the first. > >> Well, 1st - OE folks are used to monotone now. That's primary reason. > >> The second primary reason is that I know of some developers who seem to > >> dislike git. And if we're talking about technical reason, one I can > >> think of is that there's no non-ssh transport allowing push, which > >> complicates administration of our "central" repository. > > > > That's not correct. You can push to a git repository over http/webdav > > to an apache2 server. > > Theoretically. My experience is that it often fails, at least with > the kernel. But maybe this is just a git-tree maintenance issue for > the kernel devs. Chris is correct, however, that the feature is > present in git. The only difficulty I've seen with it, in hosting my own projects, is interrupted pushes. An interrupted push seems able to leave behind a stale webdav lock, which has to be manually fixed.. but that's more of a webdav with apache issue than anything else. Beyond that, you just need to ensure your permissions are correct, and set the config parameter on the repositories to indicate that they're shared, and set a hook script to executable so it can add metadata to the repo on pushes. Course, that said, I'd much rather see a git-daemon with push capability :) -- Chris Larson - clarson at kergoth dot com Dedicated Engineer - MontaVista - clarson at mvista dot com Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 18:57 ` Chris Larson @ 2007-10-04 19:11 ` Michael Krelin 2007-10-04 19:27 ` Chris Larson 0 siblings, 1 reply; 34+ messages in thread From: Michael Krelin @ 2007-10-04 19:11 UTC (permalink / raw) To: openembedded-devel > The only difficulty I've seen with it, in hosting my own projects, is > interrupted pushes. An interrupted push seems able to leave behind a > stale webdav lock, which has to be manually fixed.. but that's more of > a webdav with apache issue than anything else. Beyond that, you just > need to ensure your permissions are correct, and set the config > parameter on the repositories to indicate that they're shared, and set > a hook script to executable so it can add metadata to the repo on > pushes. Wait, how do you execute a hook when pushing via webdav? > Course, that said, I'd much rather see a git-daemon with push capability :) Agree on that ;-) Love, H ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 19:11 ` Michael Krelin @ 2007-10-04 19:27 ` Chris Larson 2007-10-04 19:39 ` Michael Krelin 0 siblings, 1 reply; 34+ messages in thread From: Chris Larson @ 2007-10-04 19:27 UTC (permalink / raw) To: openembedded-devel On 10/4/07, Michael Krelin <hacker@klever.net> wrote: > > The only difficulty I've seen with it, in hosting my own projects, is > > interrupted pushes. An interrupted push seems able to leave behind a > > stale webdav lock, which has to be manually fixed.. but that's more of > > a webdav with apache issue than anything else. Beyond that, you just > > need to ensure your permissions are correct, and set the config > > parameter on the repositories to indicate that they're shared, and set > > a hook script to executable so it can add metadata to the repo on > > pushes. > > Wait, how do you execute a hook when pushing via webdav? post-update is executed in the remote repository when pushing to it. In fact, the default post-update script in a new git init'd repository is just a script that calls git-update-server-info, so all you have to do is chmod +x foo.git/hooks/post-update and call it a day. It works just fine. -- Chris Larson - clarson at kergoth dot com Dedicated Engineer - MontaVista - clarson at mvista dot com Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 19:27 ` Chris Larson @ 2007-10-04 19:39 ` Michael Krelin 2007-10-04 20:18 ` Chris Larson 0 siblings, 1 reply; 34+ messages in thread From: Michael Krelin @ 2007-10-04 19:39 UTC (permalink / raw) To: openembedded-devel \>> Wait, how do you execute a hook when pushing via webdav? > > post-update is executed in the remote repository when pushing to it. > In fact, the default post-update script in a new git init'd repository > is just a script that calls git-update-server-info, so all you have to > do is chmod +x foo.git/hooks/post-update and call it a day. It works > just fine. *Who* executes post-update script when you push to remote repository via webdav? Love, H ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 19:39 ` Michael Krelin @ 2007-10-04 20:18 ` Chris Larson 2007-10-04 20:53 ` Michael Krelin 0 siblings, 1 reply; 34+ messages in thread From: Chris Larson @ 2007-10-04 20:18 UTC (permalink / raw) To: openembedded-devel On 10/4/07, Michael Krelin <hacker@klever.net> wrote: > \>> Wait, how do you execute a hook when pushing via webdav? > > > > post-update is executed in the remote repository when pushing to it. > > In fact, the default post-update script in a new git init'd repository > > is just a script that calls git-update-server-info, so all you have to > > do is chmod +x foo.git/hooks/post-update and call it a day. It works > > just fine. > > *Who* executes post-update script when you push to remote repository via > webdav? Sorry, my mistake on the mechanisms. The hook is only used, obviously, when pushing over ssh, since you can't run a script remotely over http. It's just that git-http-push is smart enough to update the remote info/* if the files already exist (run git-update-server-info on the remote side once). -- Chris Larson - clarson at kergoth dot com Dedicated Engineer - MontaVista - clarson at mvista dot com Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 20:18 ` Chris Larson @ 2007-10-04 20:53 ` Michael Krelin 0 siblings, 0 replies; 34+ messages in thread From: Michael Krelin @ 2007-10-04 20:53 UTC (permalink / raw) To: openembedded-devel >> \>> Wait, how do you execute a hook when pushing via webdav? >>> post-update is executed in the remote repository when pushing to it. >>> In fact, the default post-update script in a new git init'd repository >>> is just a script that calls git-update-server-info, so all you have to >>> do is chmod +x foo.git/hooks/post-update and call it a day. It works >>> just fine. >> *Who* executes post-update script when you push to remote repository via >> webdav? > > Sorry, my mistake on the mechanisms. The hook is only used, > obviously, when pushing over ssh, since you can't run a script > remotely over http. It's just that git-http-push is smart enough to > update the remote info/* if the files already exist (run > git-update-server-info on the remote side once). Good for the record, after we sorted it out on IRC. So, yes, it's theoretically possible, we'd all want to avoid it and I have no idea about its performance, which would probably need more elaborate research. I doubt, though, that onyone wants to conduct such a research at the moment ;-) Love, H ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 18:36 ` Chris Larson 2007-10-04 18:49 ` Tim Bird @ 2007-10-04 19:08 ` Michael Krelin 2007-10-04 19:28 ` Chris Larson 1 sibling, 1 reply; 34+ messages in thread From: Michael Krelin @ 2007-10-04 19:08 UTC (permalink / raw) To: openembedded-devel > > That's not correct. You can push to a git repository over http/webdav > to an apache2 server. > That's right, but I guess you also know of drawbacks of this method. To mention one, having webdav *only* for push is somewhat strange, but since at push time no hooks will be executed (which sucks by itself), including update-server-info, the repository won't be quite dumb-protocol-ready. In short, your statement is theoretically correct, but the fact you mentioned doesn't change anything. I think I've heard about some patch providing push over git protocol, which was dropped due to the lack of ssl connection support and there were talks about reinstating it along with adding ssl support. But I don't remember any details. Love, H ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: monotone/git (was hello...) 2007-10-04 19:08 ` Michael Krelin @ 2007-10-04 19:28 ` Chris Larson 0 siblings, 0 replies; 34+ messages in thread From: Chris Larson @ 2007-10-04 19:28 UTC (permalink / raw) To: openembedded-devel On 10/4/07, Michael Krelin <hacker@klever.net> wrote: > > > > That's not correct. You can push to a git repository over http/webdav > > to an apache2 server. > > > > That's right, but I guess you also know of drawbacks of this method. To > mention one, having webdav *only* for push is somewhat strange, but > since at push time no hooks will be executed (which sucks by itself), > including update-server-info, the repository won't be quite > dumb-protocol-ready. I think you're a bit behind :) post-update works just fine for this, and I'm not the only one using it on a daily basis. -- Chris Larson - clarson at kergoth dot com Dedicated Engineer - MontaVista - clarson at mvista dot com Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: hello... 2007-10-04 12:40 ` hello Holger Freyther 2007-10-04 12:55 ` monotone/git (was hello...) Tobias Pflug @ 2007-10-04 13:19 ` Michael Krelin 1 sibling, 0 replies; 34+ messages in thread From: Michael Krelin @ 2007-10-04 13:19 UTC (permalink / raw) To: openembedded-devel > Hi, > > If someone can host my mtn2git script and a git tree we can have a > git mirror almost immediately. But yes I think there are some good > reasons to stay with monotone as primary system. Does such script exist? I think the closest to it is 'tailor', which is far from perfection. I was thinking about writing one when I get time... And of course, provided you have conversion utility and hosting space you get a git miror in no time ;-) Love, H ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2007-10-09 16:58 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-10-04 10:41 hello Tobias Pflug 2007-10-04 11:18 ` hello Michael Krelin 2007-10-04 12:40 ` hello Holger Freyther 2007-10-04 12:55 ` monotone/git (was hello...) Tobias Pflug 2007-10-04 13:27 ` Holger Freyther 2007-10-04 13:50 ` Darcy Watkins 2007-10-04 13:52 ` Michael Krelin 2007-10-05 6:28 ` oe for two target boards at the same time Alex 2007-10-05 13:57 ` Cliff Brake 2007-10-05 15:47 ` Khem Raj 2007-10-06 8:19 ` Koen Kooi 2007-10-06 11:39 ` Marcin Juszkiewicz 2007-10-08 20:20 ` Cliff Brake 2007-10-09 8:28 ` Koen Kooi 2007-10-09 9:02 ` pHilipp Zabel 2007-10-09 10:36 ` Richard Purdie 2007-10-09 11:18 ` Graeme Gregory 2007-10-09 11:49 ` Graeme Gregory 2007-10-09 16:52 ` Paul Sokolovsky 2007-10-09 16:48 ` Paul Sokolovsky 2007-10-04 18:02 ` monotone/git (was hello...) Richard Purdie 2007-10-04 13:51 ` Michael Krelin 2007-10-04 13:30 ` Michael Krelin 2007-10-04 18:36 ` Chris Larson 2007-10-04 18:49 ` Tim Bird 2007-10-04 18:57 ` Chris Larson 2007-10-04 19:11 ` Michael Krelin 2007-10-04 19:27 ` Chris Larson 2007-10-04 19:39 ` Michael Krelin 2007-10-04 20:18 ` Chris Larson 2007-10-04 20:53 ` Michael Krelin 2007-10-04 19:08 ` Michael Krelin 2007-10-04 19:28 ` Chris Larson 2007-10-04 13:19 ` hello Michael Krelin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.