**** BEGIN LOGGING AT Mon Jul 06 02:59:56 2009 Jul 06 06:10:13 morning there Jul 06 06:36:55 guten morgen Jul 06 06:37:08 good morning Jul 06 06:49:58 morning Jul 06 07:14:36 quit Jul 06 07:24:19 gm Jul 06 08:09:48 gm, I've a question. I created an image for a machine with a horizontal orientated screen. But now I want to use the same machine with the screen 90 degrees rotated. What would be the best way to have psplash set correct for this? Jul 06 08:11:01 should I create a modified copy of the psplash recipe, change de PARAMS of psplash and make a differente image for both screens? Jul 06 08:11:26 Or is there a better way to solve this problem Jul 06 08:26:07 tsjsieb: I'm not sure if it solves it but I've seen some screen settings in some of the machine conf files Jul 06 08:26:35 e.g. palmtx.conf: Jul 06 08:26:36 MACHINE_DISPLAY_WIDTH_PIXELS = "320" Jul 06 08:26:36 MACHINE_DISPLAY_HEIGHT_PIXELS = "480" Jul 06 08:27:40 and also Jul 06 08:27:41 ./hx4700.conf:MACHINE_DISPLAY_ORIENTATION = "0" Jul 06 08:27:41 ./m8050.conf:MACHINE_DISPLAY_ORIENTATION = "270" Jul 06 08:33:01 morning Jul 06 08:33:59 good morning hrw Jul 06 08:34:23 MACHINE_* vars are ignored my nearly everything Jul 06 08:35:44 Viltapi: I'v seen that 't is possible to use different machine files, but I think that makes it unnecessary complex. Than I have to change the scripts in psplash checking for the machine name, while it's actually not a different machine Jul 06 08:37:28 and it will cost more acts to switch 'screens' then between the two options Jul 06 08:39:16 And I have to make 2 different images anyway, because I have to add a some other files that will be different fo the two versions Jul 06 08:41:20 the only disadvantage I can imagine is that the adapted version will not be kept 'up-to-date' inline with the upstream versions anymore Jul 06 09:04:33 good monring Jul 06 09:17:17 florian: good morning Jul 06 09:21:59 03Michael 'Mickey' Lauer  07shr/import * r5c184b3952 10openembedded.git/recipes/pulseaudio/ (libcanberra_0.10.bb libcanberra_0.12.bb): libcanberra: 0.12 -> 0.14 Jul 06 09:21:59 03Klaus Kurzmann  07shr/import * r4facdbd34e 10openembedded.git/: Merge branch 'fso/milestone5.5' into shr/import Jul 06 09:21:59 03Michael 'Mickey' Lauer  07shr/import * r3da4f1ef42 10openembedded.git/recipes/freesmartphone/fsodeviced_git.bb: fsodeviced: explictly depend on libcanberra-alsa Jul 06 09:21:59 03Klaus Kurzmann  07shr/import * r4b1ea0c0c2 10openembedded.git/recipes/e17/ (4 files in 2 dirs): Jul 06 09:21:59 e-wm_svn.bb: add TreviƱos click patches for SHR Jul 06 09:21:59 Signed-off-by: Klaus Kurzmann Jul 06 10:22:55 time to flood! Jul 06 10:23:06 03Michael Smith  07stable/2009 * r3552380508 10openembedded.git/recipes/ (15 files in 10 dirs): Jul 06 10:23:06 Remove references to base_set_filespath() from recipes that don't need it. Jul 06 10:23:06 These recipes are covered by the default FILESPATHPKG setting. Jul 06 10:23:06 Signed-off-by: Michael Smith Jul 06 10:23:06 Acked-by: Tom Rini Jul 06 10:23:08 Signed-off-by: Marcin Juszkiewicz Jul 06 10:23:12 Acked-by: Denys Dmytriyenko Jul 06 10:23:14 03Chris Larson  07stable/2009 * r29428be0b6 10openembedded.git/recipes/kexecboot/linux-kexecboot.inc: (log message trimmed) Jul 06 10:23:17 kexecboot: require ../linux/linux.inc, not recipes/linux/linux.inc. Jul 06 10:23:19 linux-kexecboot.inc does a 'require recipes/linux/linux.inc', but it really Jul 06 10:23:21 depends on how the upstream OpenEmbedded linux/linux.inc behaves, not whatever Jul 06 10:23:25 the first one it finds in BBPATH does. This broke builds for me combining Jul 06 10:23:27 upstream OpenEmbedded with some local collections that do different things Jul 06 10:23:29 with their kernels. Jul 06 10:23:31 03Andrea Adami  07stable/2009 * r44c54ea109 10openembedded.git/recipes/linux/ (2 files in 2 dirs): (log message trimmed) Jul 06 10:23:34 linux-rp-2.6.23: fix compilation with gcc-4.3 Jul 06 10:23:36 Since some architectures don't support __udivdi3(). Jul 06 10:23:40 Signed-off-by: Segher Boessenkool Jul 06 10:23:42 Cc: john stultz Jul 06 10:23:44 Cc: Ingo Molnar Jul 06 10:23:46 Signed-off-by: Andrew Morton Jul 06 10:23:48 03Andrea Adami  07stable/2009 * re39487bd82 10openembedded.git/recipes/linux/ (2 files in 2 dirs): (log message trimmed) Jul 06 10:23:51 linux-rp-2.6.24: fix compilation with gcc-4.3 Jul 06 10:23:59 Since some architectures don't support __udivdi3(). Jul 06 10:24:01 Signed-off-by: Segher Boessenkool Jul 06 10:24:03 Cc: john stultz Jul 06 10:24:05 Cc: Ingo Molnar Jul 06 10:24:07 Signed-off-by: Andrew Morton Jul 06 10:24:09 03Koen Kooi  07stable/2009 * r72440a2db1 10openembedded.git/conf/bitbake.conf: Jul 06 10:24:15 bitbake.conf: weakly assign OLDEST_KERNEL ?= "2.4.0" *after* machine and distro configs are included Jul 06 10:24:17 Signed-off-by: Marcin Juszkiewicz Jul 06 10:24:19 Acked-by: Denys Dmytriyenko Jul 06 10:24:21 03Roman I Khimov  07stable/2009 * r2ba25437fa 10openembedded.git/recipes/ (eglibc/eglibc-package.bbclass glibc/glibc-package.bbclass): (log message trimmed) Jul 06 10:24:24 (e)glibc-package: fix kernel version passed to qemu Jul 06 10:24:30 Binary locale generation fails with Jul 06 10:24:32 FATAL: kernel too old Jul 06 10:24:34 if (e)glibc is configured for kernels newer than 2.6.16. This comes from Jul 06 10:24:36 kernel version check in sysdeps/unix/sysv/linux/dl-osinfo.h. We configure Jul 06 10:24:38 (75 lines omitted) Jul 06 12:43:14 gm Jul 06 13:41:07 hello, I'm looking for a doc explaining howto use McSPI, is there any good doc? Jul 06 13:52:20 03Felix Domke  07org.openembedded.dreambox * r8f43bbf9af 10openembedded.git/packages/sysvinit/ (sysvinit/dm8000/inittab sysvinit_2.86.bb): sysvinit,dm8000: fix serial port Jul 06 13:57:11 morning pb_ Jul 06 13:58:25 morning Jul 06 14:12:33 hi rkirti Jul 06 14:19:39 hi are there some people who use micro? if so does init goes to runlevel 5 becuase it doesn't seems to want to exectute a runlevel Jul 06 14:19:44 other than S Jul 06 14:23:14 hello, I'm looking for a doc explaining howto use McSPI, is there any good doc? Jul 06 14:24:14 Hi Gnutoo. Using micro here. Jul 06 14:24:33 yes but you are using custom init Jul 06 14:24:44 s/init/init scripts Jul 06 14:24:59 Gnutoo: yes. No login. Jul 06 14:25:08 ok Jul 06 14:26:57 you use a shell script instead of init? Jul 06 14:27:04 Gnutoo: yes Jul 06 14:27:07 ok Jul 06 14:27:56 I wonder if I should do the same rather than fixing init...but I would have problem with init scripts such as dropbear etc...I would have to call them manually Jul 06 14:28:44 Gnutoo: are you using the default init or your own? Jul 06 14:29:26 Is the default init for micro "busybox init"? Jul 06 14:29:30 the default,that is init.sysvinit Jul 06 14:29:57 if I remember well the init was in the image not the distro Jul 06 14:30:06 I built micro-base-image Jul 06 14:30:14 Ah, ok Jul 06 14:30:59 Gnutoo: you are right: IMAGE_INIT_MANAGER = "sysvinit sysvinit-pidof" Jul 06 14:31:31 Gnutoo: there's also IMAGE_INITSCRIPTS = "". Can't you add the scripts you want to run to this variable? Jul 06 14:31:42 yes I can Jul 06 14:31:58 I'll do it Jul 06 14:32:06 And that's what you don't want to do? Jul 06 14:32:38 what I want to do is to use sysvinit-pidof and make it go to runlevel5,modifying /etc/inittab or something else Jul 06 14:32:55 ok Jul 06 14:33:43 I've already modified mdev.sh to create the ttyS{0,1} Jul 06 14:33:59 but that's not the problem Jul 06 14:34:15 it should have start dropbear and network Jul 06 14:34:59 s/network/syslog Jul 06 14:35:50 it stops there: http://www.pastebin.ca/1485715 Jul 06 14:35:57 and runlevel5 have: Jul 06 14:36:05 S10dropbear S20syslog Jul 06 14:36:30 and inittab has id:5:initdefault: Jul 06 14:38:14 http://www.pastebin.ca/1485716 (previously the serial console was S:2345:respawn:/sbin/getty 115200 ttyS0 and it didn't work either becuase of the runlevel5 problem) Jul 06 14:46:20 Gnutoo: do you know inittab's syntax? (I don't know much). I've noticed the line 116 from http://www.pastebin.ca/1485715 has a single S. OE's inittab has the following lines: Jul 06 14:46:25 # What to do in single-user mode.~~:S:wait:/sbin/sulogin Jul 06 14:46:45 Better: Jul 06 14:46:46 # What to do in single-user mode. Jul 06 14:46:46 ~~:S:wait:/sbin/sulogin Jul 06 14:46:46 Jul 06 14:47:26 inittab's man page contains an example which is just the same, but the line starts with a single ~: Jul 06 14:47:33 ok Jul 06 14:47:36 thanks a lot Jul 06 14:47:44 # What to do in single-user mode. Jul 06 14:47:45 ~:S:wait:/sbin/sulogin Jul 06 14:48:24 That looks suspicious. Jul 06 14:52:14 mmm....strange... Jul 06 14:52:26 it works with the openmoko but not the wrt54gs Jul 06 14:52:40 I've copied openmoko's initrd to the NFS root Jul 06 14:52:59 or maybe Jul 06 14:53:11 it could be a dependency problem Jul 06 14:53:21 becuase networking doesn't start... Jul 06 14:53:47 dropbear and syslog don't start Jul 06 14:53:52 and so the console doesn't start Jul 06 15:00:46 hi all Jul 06 15:00:52 I'll try something Jul 06 15:01:15 hi thesing Jul 06 15:02:05 florian: was there anything important in oe in the last 6 months? Jul 06 15:02:33 thesing: oh... quite some changes, we all have been busy. Jul 06 15:03:41 is there something that I should absolutely look into? Jul 06 15:05:17 latest mails about oe e.v. on the list maybe... and of course there were quite a lot of checkins since then Jul 06 15:55:27 We need more stable/2009 maintainers... Jul 06 16:16:45 stuff not getting reviewed fast enough? Jul 06 16:45:27 have a nice rest of day Jul 06 16:45:49 Tartarus: there are some stable/2009 patches which lacks acks.. Jul 06 16:45:58 http://patchwork.openembedded.org/project/openembedded/list/?state=*&q=oe%2CSTABLE Jul 06 16:47:07 hrw: ack and yes... have a nice time Jul 06 17:07:38 did anyone do a crazy crazy thing and try and get kde4 to build under bitbake or so? just curious if someone did the work I am about to reproduce :D Jul 06 17:27:40 hey guys did the poky virtualnative stuff make it into OE dev? Jul 06 17:28:31 or should I say did anyone consider it? Jul 06 19:13:18 re Jul 06 19:44:10 newbie question: how / where can I find what's the uboot_entrypoint variable? Jul 06 19:53:19 lisandropm: its defined in the machine config files Jul 06 19:54:15 yes, the problem is that I don't know to what it refers Jul 06 19:54:18 :-) Jul 06 19:55:49 excep some of those files explain it :-) Jul 06 19:56:36 yes... something like UBOOT_ENTRY_POINT or similar.... just take a look at soem other file usin u-boot Jul 06 19:58:40 its used when making uimage Jul 06 19:59:14 check classes/kernel.bbclass Jul 06 20:06:53 usually its entry point as encoded in the kernel ELF file (vmlinux) Jul 06 20:07:41 khem: thanks! Jul 06 20:43:16 Bah, silly gmp doesn't use $(includedir) to decide where to stick includes, but rather $(exec_prefix)/include Jul 06 20:57:51 is there any way to change the default blue text color in angstrom? Jul 06 21:08:55 03Florian Boor  07org.openembedded.dev * r58d6c0ace0 10openembedded.git/recipes/linux/ (3 files in 2 dirs): linux: Update 2.6.30-rc4 with more tx25 patches. Jul 06 21:19:39 what is the correct solution when you want to set TOPDIR (used by bitbake), and a Makefile is also using it (net-tools) Jul 06 21:23:30 I don't like tmp ending up in some random 'pwd' location Jul 06 21:44:19 cbrake: a makefile using it shouldnt be a problem unless it's a non-autotools based buildsystem, TOPDIR is exported (unsure), and you're using the default EXTRA_OEMAKE, which results in env vars overriding makefile vars by default . you can always override EXTRA_OEMAKE to explicitly pass the flags/cc/etc instead. Jul 06 21:45:09 kergoth: yup, non-autotools based project Jul 06 21:45:36 probably the best bet is either to unexport TOPDIR in the recipe, or override the default EXTRA_OEMAKE Jul 06 21:46:14 kergoth: nod, that is cleaner than patching the source Jul 06 21:47:04 kergoth: what is the syntax to unexport TOPDIR in the recipe? Jul 06 21:47:33 the default EXTRA_OEMAKE is .. scary, but it does make most non-autotools buildsystems work with less manual passing of vars in, but I'd say its always preferred to explicitly pass them, since it ensures that the recipe maintainer has taken the time to analyze the buildsystem and determine what vars they obey and how best they pass them in Jul 06 21:47:39 TOPDIR[unexport] = "1" Jul 06 21:47:52 should do it, thats how MACHINE is done in base.bbclass (because of binutils, etc using it) Jul 06 21:48:04 personally I'd say they should always be xplicitly unexported in the recipes in question, not globally in base.bbclass. Jul 06 21:48:06 but .. Jul 06 21:49:32 sounds good, thanks for the help Jul 06 21:49:35 np Jul 06 21:50:10 heh, i was the one that came up with that default extra_oemake, did it to try to keep as many recipes simple and clean as possible Jul 06 21:50:10 looks like the perl recipe could be cleaned up a bit that way Jul 06 21:50:26 heh, every recipe we have could be cleaned up in one way or another :) Jul 06 21:50:30 :-) Jul 06 21:51:51 hmm, someone should take the time to move those unexports into the recipes at some point, doing it globally when it only affects a few recipes is pretty disgusting. although, arguably, those vars don't need to be exported to begin with. imo the only vars that should be exported are those that will be used by configure or toplevel makefiles: cc, ld, etc & cflags, ldflags, etc Jul 06 21:57:23 03Cliff Brake  07org.openembedded.dev * r178ea3236f 10openembedded.git/recipes/net-tools/net-tools_1.60.bb: net-tools: unexport TOPDIR in recipe as it is used by the makefile Jul 06 21:57:39 cbrake: that took care of it? Jul 06 21:57:48 kergoth: yes :-) Jul 06 21:57:52 nice Jul 06 21:58:45 kergoth: apparently it is only a problem if TOPDIR is in BB_ENV_EXTRAWHITE Jul 06 21:59:00 kergoth: as the env gets cleaned Jul 06 21:59:06 ahh, so its normally not exported, but because it came in through the env, it gets forced as a re-export Jul 06 21:59:14 makes sense Jul 06 21:59:24 ugh what kind of idiot sets TOPDIR in their environment? :/ Jul 06 21:59:46 quite a few, I'm sure. personally i prefer to set OEROOT and set TOPDIR in local.conf based on it Jul 06 22:00:03 kergoth: but, I like to explicitly set TMPDIR (via TOPDIR) so tmp is always in the same place Jul 06 22:00:05 cbrake: i kind of question the forced re-export in bitbake, maybe we should explicitly export the important ones, like HOME Jul 06 22:00:25 I use the Poky env script.... Jul 06 22:00:42 and TMPDIR is under the directory I put my script for each build configuration Jul 06 22:01:01 so source /build/systems/beagleboard/profile.sh and all the files are in /build/systems/beagleboard/tmp.3 or so Jul 06 22:01:10 Neko: URI for env script? Jul 06 22:02:06 http://git.pokylinux.org/cgit.cgi/poky/tree/scripts/poky-env-internal Jul 06 22:02:26 kergoth: yeah, there seems to be two groups of variables -- those needed by bitbake, and those like HOME that always be in the env Jul 06 22:02:28 I made a few changes but Jul 06 22:02:43 I never used stuff like TOPDIR even when I made a script by hand Jul 06 22:02:55 I had always, always used this in Makefiles for big projects Jul 06 22:02:57 cbrake: yeah, but we can set flags on them in the .conf files even if we aren't setting the vars there, which I'd think would be better rather than doing it implicitly Jul 06 22:03:09 * kergoth adds to his list of OpenEmbedded issues Jul 06 22:03:48 ah while kergoth is here.. and anyone else... is it safe to put packaged-staging directory in a shared location and have multiple builders writing to it and updating stamps etc.? Jul 06 22:04:42 Neko: this script requires you to run bitbake from the directory above tmp I believe Jul 06 22:04:47 I would assume opening the file for writing is all the locking bitbake would need not to trash another processes write (since it's multithreaded) but I am not entirely sure Jul 06 22:04:49 stamps don't go in the pstage dir, so thats a nonissue, the only issue would be possible races on the write of the pstage ipks, could always add a file lock there Jul 06 22:05:01 cbrake, yeah but you can fix that with the OEROOT define at the top Jul 06 22:05:20 personally I pass in the machine name as an argument Jul 06 22:05:30 but even in a failure case, it wouldnt break anything, just writes it twice, I'd think.. the breakage would be if there were differences in the build that weren't reflected in the pstage ipk filenames Jul 06 22:05:33 also the repositories are differently named (meta- instead of recipes etc.) so I hacked that Jul 06 22:05:37 i.e. changed TARGET_FPU or something Jul 06 22:05:43 * kergoth shrugs Jul 06 22:06:03 Neko: bitbake does not use OEROOT Jul 06 22:06:05 kergoth, well that shouldn't change.. the worst that could happen is, it builds an ipk twice, or maybe compiles it from scratch? Jul 06 22:06:13 Neko: it gets TOPDIR from env or pwd Jul 06 22:06:16 cbrake, OEROOT is not for bitbake it's for the rest of the script Jul 06 22:06:26 Neko: yeah, thats what I'm thinking Jul 06 22:06:26 bitbake wants BBPATH, nothing else Jul 06 22:06:48 it goes to cd to a directory and then TOPDIR = pwd while building Jul 06 22:07:11 simple example... build something in gnome-terminal and while building do ctrl-shift-t to open a new tab Jul 06 22:07:18 the new bash prompt will open in the directory bitbake is operating in Jul 06 22:07:27 * kergoth uses a project setup script when he creates the build area, it emits the hardcoded path of TOPDIR into the local.conf when it sets it up Jul 06 22:07:28 Neko: right, I want TOPDIR in a "FIXED" location, but some random pwd location based on where I happened to run bitbake Jul 06 22:07:48 but, topdir is not up to you Jul 06 22:07:58 if you want to change where the work directory is, move tmpdir Jul 06 22:08:01 eh? Jul 06 22:08:05 you can change TOPDIR all you like Jul 06 22:08:14 its the root of the build area, by definition Jul 06 22:09:04 yeah as used by 1000s of opensource projects in makefiles, including Mesa for example :) Jul 06 22:09:18 which is why it's not exported by default Jul 06 22:09:32 it just gets re-exported when you set it via the environment, as a side effect of how the env whitelisting code functions in bitbake Jul 06 22:09:35 putting it in the whitelist is bordering on retarded Jul 06 22:09:47 no, bitbake re-exporting every var it gets in the env is Jul 06 22:10:37 oh for f******.............. virtualbox crashes again Jul 06 22:10:41 Sun have a lot to answer for this year Jul 06 22:10:47 * cbrake ahh, just what I always feared, I'm bordering on retarded :-) Jul 06 22:10:53 * kergoth chuckles Jul 06 22:11:49 * kergoth grumbles, today sucks Jul 06 22:12:14 the idea of the whitelist is to let certain variables pass through which are safe.. and the idea of the extra whitelist list is to let through some variables which you may use in a custom manner (like OEROOT which is not bitbake or OE but just a convention people like to use.. or OE_ROOT or MY_BUILD_TOP_FOLDER or whatever) Jul 06 22:12:45 the idea of the whitelist is to let bitbake obey those variables, not necessarily to put those in the builds of the recipes. Jul 06 22:12:55 it flows into the metadata, not necessairly back out, imo Jul 06 22:13:10 looks like freeze.inc also uses TOPDIR, but not much else Jul 06 22:13:27 not dictated or wrong, but it's like wearing brown belt with brown shoes. Jul 06 22:13:59 TOPDIR is the root of the build, adding a new variable when you can just set the existing one to work around issues with builds is just stupid Jul 06 22:14:14 define "the root of the build"? Jul 06 22:14:33 exactly what i said. everything is relative to it Jul 06 22:14:38 everything? Jul 06 22:14:39 nothing goes outside of it Jul 06 22:14:48 unless explicitly pointed there Jul 06 22:14:50 in what context? Jul 06 22:14:52 all default paths are relative to it Jul 06 22:15:24 so bitbake sets TOPDIR once, which is to.. /where/I/checked/out/openembedded? Jul 06 22:15:27 every _DIR variable in our bitbake.conf is relative to TOPDIR eventually, most just happen to also be relative to TMPDIR, but that's certainly not guaranteed Jul 06 22:15:32 no, TOPDIR by default is $PWD Jul 06 22:15:35 its just a default. Jul 06 22:15:39 right Jul 06 22:15:51 persoanlly, i have all sorts of stuff moved to paths relative to TOPDIR rather than being in tmp Jul 06 22:15:52 but it is that way because bitbake goes into a directory to run make or configure Jul 06 22:15:54 pstage binaries, sources, etc Jul 06 22:15:59 what? Jul 06 22:16:08 well when an archive is extracted Jul 06 22:16:15 make and configure are always run relative to the dirs flag of the task Jul 06 22:16:19 which is generally ${S} Jul 06 22:16:24 it cd into whereever and that is then pwd Jul 06 22:16:35 TOPDIR is set to the *current* pwd when you start the build. Jul 06 22:16:37 it doesn't magically update Jul 06 22:16:44 its always where you started the build Jul 06 22:16:45 yikes Jul 06 22:16:54 once again, TOPDIR is the root of the build. Jul 06 22:17:54 that doesn't sound terribly sane to me, except for the fact that setting tmpdir, dl_dir, etc. move 100% of this out of the way so it never touches anything in the directory you randomly happen to be in when you run bitbake? Jul 06 22:18:09 later Jul 06 22:18:13 I assume this is on the assumption that you are running OE out of your home directory or something Jul 06 22:18:16 I fail to see your point Jul 06 22:18:51 no, the assumption is you're running your build from a build area, where the build output is going, which also usually contains conf/local.conf, the config associated with this build output, but that's just a convention Jul 06 22:19:38 well, it seems to me that the entire build system therefore makes the assumption that the directory you typed "bitbake" in, is yours, writable by you, is where you wanted to put the files, that the shell you are in is not used for anything else previously except to source the environment and make sure you are in the right directory in the first place? Jul 06 22:20:00 would you rather it hardcoded an output path? Jul 06 22:20:04 thatd be fucking stupid Jul 06 22:20:06 no Jul 06 22:20:10 relative to the current dir is the only default that makes any sense Jul 06 22:20:19 but, this is what BBPATH is for, no? Jul 06 22:20:23 no. Jul 06 22:20:28 BBPATH is how bitbake finds its files, thats all Jul 06 22:20:29 then why bother filling BBPATH at all? Jul 06 22:20:32 it has absolutely nothing to do with the output Jul 06 22:20:36 bitbake will search for config there Jul 06 22:20:42 do you expect it to magically find the openembedded files, then? Jul 06 22:20:46 the current dir isn't the only location of files Jul 06 22:20:57 it doesn't have pixie dust that enables it to locate your overlays/collections Jul 06 22:21:18 right but once you set BBPATH using your env script, conf/local.conf is in that location, and then that file can list the locations of overlays and collections Jul 06 22:21:40 I don't think I am particularly alone in thinking this way considering all the docs, all the OE derivatives use this as a starting point Jul 06 22:22:09 no Jul 06 22:22:16 i really dont see your point Jul 06 22:22:20 Poky does it all in the env script. BeagleboardOpenEmbeddedGit wiki page does it half in the env script and overrides it in local.conf Jul 06 22:22:28 and? Jul 06 22:22:41 all of them completely remove any assumption of what the current dir is by relocating where bitbake will think topdir is Jul 06 22:22:49 to the point that topdir is irrelevant anyway Jul 06 22:23:18 I'm happy for them, that doesn't change the fact that topdir was originally intended to be the root of the build. Jul 06 22:23:18 if topdir is the root of the build it also assumes that every recipe is therefore underneath that durectory Jul 06 22:23:21 i ought to know, i wrote bitbake.conf Jul 06 22:23:25 no, itd oesnt. Jul 06 22:23:36 the build doesn't imply your collections are there Jul 06 22:23:37 aha! I caught you... then why is topdir so important Jul 06 22:23:40 never has, never will Jul 06 22:23:50 BBPATH is how it finds config & classes, BBFILES is how it finds recipes Jul 06 22:24:09 all TOPDIR is is the location the default paths are relative to, including TMPDIR Jul 06 22:24:10 and tmpdir and dl_dir and deploy_pstage_dir is where it puts other files... Jul 06 22:24:26 and no one will ever output anything else that isnt in tmpdir? Jul 06 22:24:27 ideally you'd be setting those in your config or env script Jul 06 22:24:28 that's a flawed assumption Jul 06 22:25:18 sure, you can override every var thats based on topdir, if you really want to, you're welcome to it Jul 06 22:25:23 I never made that assumption. there are variables for moving stuff out of tmpdir Jul 06 22:25:29 just seems silly when there's already a dir thats supposed to act as the top of the build Jul 06 22:26:21 maybe I am just not used to this kind of build environment.. I am used to either manually going into a directory and typing "make" (which always works because I write my makefiles :) or I do something like emerge in gentoo Jul 06 22:26:25 but again, if you want to structure it that way, you're welcome to it, but saying using TOPDIR is wrong is just silly, thats what it was created for. Jul 06 22:26:28 emerge never uses the current dir to do anything Jul 06 22:26:35 of course it doesn't Jul 06 22:26:38 there are defined locations in the system for it Jul 06 22:26:39 its part of the Linux distro Jul 06 22:26:48 i have 37 different build areas for OpenEmbedded right now Jul 06 22:26:57 of course, since you are not part of the distro, you should be defining where these locations are before running it Jul 06 22:26:59 I'd be awfully pissed if it shoved something into /var or something Jul 06 22:27:14 not assuming "hmm, I will make a guess and say the directory you are in now is where I should dump 30GB of tmp files" Jul 06 22:27:37 what part of "default" isn't sinking in? Jul 06 22:27:49 where would be a better place? some random hardcoded location? that'd be fucking stupid Jul 06 22:27:49 where I come from, pwd is no reasonable default :D Jul 06 22:27:58 no, leave it undefined and complain Jul 06 22:28:05 then its a good thing i don't give a shit where you come from, isn't it? Jul 06 22:29:03 just like when I run bitbake 1.9 it says "WARNING, WARNING, WARNING" and waits for 5 seconds.. is it not possible to say "uhh, you never set TMPDIR, are you really sure you actually want to do the entire build in pwd? I am going to sit here and let you think about it for a second (press a key to carry on but don't blame me if you run out of disk space or doin't have permissions for this dir or something)" Jul 06 22:29:45 it's hardly likely that anyone would install an openembedded tree without reading any kind of docs at some point in their lives, so you could say the fact that TMPDIR is not defined by anything when bitbake is run, is a documentation bug more than anything Jul 06 22:29:52 hahaha Jul 06 22:29:55 do you know nothing about users? Jul 06 22:30:01 we have people in here EVERYD AY that haven't read any docs at all Jul 06 22:30:15 always have, always will Jul 06 22:30:28 yes which is why local.conf.sample has 3 or 4 little tricks to make sure they read it Jul 06 22:30:43 one more little trick and a doc url would not hurt, would it? Jul 06 22:30:45 and you think that means they actually will? Jul 06 22:30:55 well, if they don't, they will not get very far, will they? Jul 06 22:30:57 maybe in your fantasy world Jul 06 22:30:58 not here Jul 06 22:31:15 i don't see why you want to make users lives harder, requiring even more setup than it does now Jul 06 22:31:17 it makes absolutely no sense Jul 06 22:31:29 your'e also the only person I've seen bitch about this in the 5+ years we've had that default Jul 06 22:31:34 I believe firmly in when you get a new toy that you read the instructions before plugging it in... Jul 06 22:31:42 you're in the minority Jul 06 22:31:58 kergoth, the ironic thing is that I read all the docs, and they said "set TMPDIR" so I did, so I never saw this issue until it was discussed right now Jul 06 22:32:15 bitbake never had the opportunity to dump files where I did not tell it to :D Jul 06 22:32:18 and setting TMPDIR works just fine, it just happens to default to ${TOPDIR}/tmp, which is $PWD/tmp Jul 06 22:32:34 I'm happy for you, but there are more ways to set up and use bitbake than just that way Jul 06 22:32:51 I also read something about appending DISTRO_PR to the tmpdir so that you can do multiple builds with multiple distro releases Jul 06 22:33:22 you know what OE needs is a GUI installer or something, then there would be no need for docs.... :D Jul 06 22:33:38 MontaVista got it right. did you try their stuff yet? Jul 06 22:33:53 .. Jul 06 22:33:55 i work for montavista Jul 06 22:33:57 on mvl6 Jul 06 22:34:05 :) Jul 06 22:34:08 right, so... you know exactly what I mean then Jul 06 22:34:26 even hardcore embedded developers cannot live without a graphical setup tool :D Jul 06 22:34:33 .. Jul 06 22:34:39 of course they can, they do every day, and MANY prefer it that way Jul 06 22:34:47 particularly the board bringup folks, that usually use buildroot or something Jul 06 22:35:11 if they could then ARM would not try and get everyone to use Eclipse and Freescale would not still ship LTIB and the Linux kernel would not have qconfig :] Jul 06 22:35:30 ? Jul 06 22:35:34 that doesn't mean they cant live without it Jul 06 22:35:39 that means some people prefer guis Jul 06 22:35:43 your logic is flawed, again Jul 06 22:35:49 you'd be surprised how much support we have to do for people who are so used to LTIB Jul 06 22:36:06 we give them buildroot or a custom thing for their purpose and they say "but.. Freescale's tool had a GUI, I can't use a shell" Jul 06 22:37:03 so a subset of the embedded developers, specifically those who contact you for support like guis. assuming the entire embedded Linux community works that way because a small not necessarily representative subset does is flawed Jul 06 22:37:25 and even then, its a preference, not a "can't live without" Jul 06 22:37:51 as for board bringup, we rely on firmware for that... most of our business model relies on not having to recreate an entire BSP for every board revision that comes out of every place, we just port the firmware and the abstractions handle it for them. We've got the same kernel running on multiple ARM boards right now, they have no clue that the serial controller is different or that interrupts are cascaded through an FPGA that emulates an i8259 or freakish stuff li Jul 06 22:37:51 ke that Jul 06 22:38:35 btw speaking of bitbake 1.9, is it even meant to be usable? Jul 06 22:38:45 pretty sure trunk is just plain broken right now Jul 06 22:38:51 it seems that way Jul 06 22:39:13 there are really only a few of us who care about long term improvements to bitbake/oe enough to actually work on such things, and we've been busy with other things Jul 06 22:39:28 most of the work on trunk was richard, and i dont know how much time he has what with being absorbed by intel and all Jul 06 22:39:43 I follow zecke's blog and he's been saying he will finish the parser... I wanted to see Jul 06 22:40:15 kergoth, he seems to be doing a lot for Poky.. Jul 06 22:40:29 I also wanted to look at the virtualnative stuff too Jul 06 22:40:43 that seems to be consuming most of his time, and trying to get stuff pushed up to the community Jul 06 22:40:46 seems that is just hosed right now and not touched for 6 months.. did this go anywhere? Jul 06 22:41:23 I'd personally like to see the virtualnative bits change slightly, to allow programmatic creation of variants rather than only being able to do one per bbclass, but .. haven't had the time to spend on it Jul 06 22:41:30 it is the kind of secret internal project that happens, with no docs and no announcement, and LOOKS cool from the outside, and then gets left forever...? Jul 06 22:41:33 maybe i can convince mv to let me mess with it after our public release Jul 06 22:41:41 :) Jul 06 22:41:49 maybe I can convince Bill to pay MV for it Jul 06 22:41:58 or maybe we can convince Freescale to pay for it Jul 06 22:42:16 approaching release, things are getting hectic, all bugfix work, no fun stuff anymore :) Jul 06 22:43:33 in an ideal world everyone would quit dicking with U-Boot and stop using LTIB and Scratchbox. And then we can be in paradise. Jul 06 22:44:26 well, to be fair, scratchbox better meets the needs of the active developer use case than we do Jul 06 22:44:30 not that Scratchbox is bad but like most stuff in this area (apart from OE or a custom toolchain and scripts like LTIB), half the useful platforms are languishing in experimental stages Jul 06 22:44:48 we've got distro folk, build folk, etc happy, but the build/test cycle using bitbake and mesing with bits buried deep in tmpdir is a pain in the ass when you're actively coding something Jul 06 22:44:57 I think it better meets the needs of people who have too much time on their hands. Jul 06 22:45:24 I like the fact that I got openembedded building me a beagleboard image in all of 20 minutes.. of course it is taking me 14 hours to build it, but.. that is by the by Jul 06 22:45:52 I'd disagree, scratchbox makes the cross bits transparent, which speeds up the development process. of course, it means that the user doesn't become aware of cross issues that way, and big builds are slowed down by it, but it does speed up the build/test cycles of the application developer, for example Jul 06 22:46:33 right but unless you're coding something very hardware specific, there isn't much need to cross compile except to test it on the target Jul 06 22:46:52 * kergoth would like to incorporate some aspects of it into our stuff at some point, use it to produce our autoconf test results for a new platform, for example Jul 06 22:47:40 don't get me wrong, i think OpenEmbedded is the better tool for general maintainance of embedded Linux distros, i just think we need to improve our support for the app developer use case Jul 06 22:47:56 okay well I think there are a couple things you could do here Jul 06 22:48:05 which are very similar to the way building for debian etc. sucks Jul 06 22:48:36 if you use debuild or dkpg-buildpackage the damn thing *cleans* on every build. you have no control over what really gets done, either Jul 06 22:48:37 tmp structure is too convoluted, for one. you shouldnt have to tab complete 42 times to get to the source tree :) Jul 06 22:48:53 it would be nice to be able to have a recipe that forced $S and $D to places you wanted Jul 06 22:49:06 so the source is in your home dir, the active source tree... Jul 06 22:49:19 you do not need to check it out from svn to compile it every time or create a tarball Jul 06 22:49:24 i want better support for storing the recipe for the project in the project's source tree, putting its build output relative to that location, etc Jul 06 22:49:35 yeah, exactly Jul 06 22:49:57 and every time you increment a build, you can watch it fail, edit the file comfortably, and start where you left off Jul 06 22:50:08 yeah, that would be very nice Jul 06 22:50:13 I got a python build going yesterday and after 2 hours of compiling it failed at the last tests.. Jul 06 22:50:17 I'd like to change the way you configure and use bitbake in general Jul 06 22:50:26 BBPATH, BBFILES, those were hacks to get things functional Jul 06 22:50:27 I ran debuild again like an idiot and it deleted all the work. 2 hours later I got bored. Jul 06 22:50:29 just never went back and changed it Jul 06 22:50:51 COLLECTIONS makes things easier, but I'd like to see more changes Jul 06 22:51:02 but then, I'd like to see just about everything change eventually :) Jul 06 22:51:47 life is too short to do a "clean" package, I am glad OE doesn't do that, but the basic problem is that it's too hard to clean with bitbake (especially as it takes so long) and all your temp and work and patches are stuffed into some 500-character-long directory, which.. is a clickable link in my terminal which is nice.. but still annoying. I think this is not the worst part of any build environment I have ever used though. Jul 06 22:52:10 my dream is to be able to do something like... mkdir projectdir; cd projectdir; bbsetup -m mymachine -d mydistro; bbsetup -i busybox, which would be like apt-get, itd grab the sources, recipe, ettc and its deps and drop it into my projectdir, so you only see the bits you want to be building Jul 06 22:52:15 I especially like oestats Jul 06 22:52:43 I build in VMs a lot and sometimes the clipboard daemon dies or is not installed.. or it built on a system that has no easy display Jul 06 22:53:01 having it on some server as a text file is so useful, better than copying out of PuTTY into pastebin Jul 06 22:54:10 right that is it Jul 06 22:54:19 virtualbox 3.0 is out of the door, back to 2.1 I go Jul 06 22:55:07 god forbid any of these Sun engineers migrate to Oracle projects Jul 06 22:55:27 or we'll all end up using MS SQL by the end of the year as the "best database server on the market" :D Jul 06 22:55:29 * kergoth chuckles Jul 06 22:56:05 at least when it crashes it doesn't leave a 512MB java web interface running though, no thanks to vmware. Jul 06 22:56:43 oh well. 8-core xenserver box tomorrow. I can ditch local vms forevers. Jul 06 22:58:19 * kergoth really needs to work on taking deep breaths and breaks to avoid getting annoyed, found himself getting a bit worked up there, thought he'd managed to avoid that Jul 06 23:36:41 Hmm, Anyone know why gcc-cross{,-sdk}_4.* has --disable-libunwind-exceptions but gcc-initial doesn't? And why we disable that explicitly at all? Jul 06 23:37:06 And, er, OK, der, I know why it's not spelled out in -initial Jul 06 23:39:26 Or rather, I know why it doesn't end up in what we do in -initial, but if it's an important thing, why is it not there? Jul 06 23:42:17 RP? git log implies this came from you in 06904ed971e17216c41f58906d3a07d636e857c1 Jul 07 00:00:46 * Tartarus digs harder Jul 07 00:05:16 * Tartarus kicks git Jul 07 00:07:50 Bah, is there mtn or BK history in a git tree somewhere? Jul 07 01:27:05 03Tom Rini  07org.openembedded.dev * rd1767a1edb 10openembedded.git/recipes/gmp/ (4 files in 2 dirs): gmp: Fix a problem when ${exec_prefix} != ${includedir}, switch to INC_PR **** ENDING LOGGING AT Tue Jul 07 03:00:06 2009