**** BEGIN LOGGING AT Fri Jul 09 02:59:57 2010 Jul 09 04:43:06 (vpn-hsv, vpn-sjc, ...) Jul 09 04:54:03 khem, unixbench on mipsel, gcc-4.4.4 vs gcc-4.5: http://pastebin.com/E2r8sD1n Jul 09 04:54:29 that is on real hardware, i just used the qemu machine target Jul 09 04:54:55 there may be slight errors in the filesystem tests as i'm using nfsroot Jul 09 05:26:31 grg: cool thx Jul 09 05:26:40 grg: gcc 4.5 is notch better Jul 09 05:27:11 now if you enable -flto and -fwhole-program then it will make real difference Jul 09 05:27:17 khem, yeah. Pipe throughtput is an odd one. Jul 09 05:27:55 hmm yeah Jul 09 05:28:58 i'm assuming the slight speed regression with shell scripts is due to the regression in pipe throughput Jul 09 05:29:34 could be Jul 09 05:30:16 actually you could tar up the build dirs for the benchmark Jul 09 05:30:28 and put it somewhere I can access Jul 09 05:33:19 khem, i don't really have anything publicly accessible... Jul 09 05:33:25 i could email Jul 09 05:37:59 hrmm, bitbake -c configure virtual/kernel doesnt work? Is there a better way to run this command or something? Jul 09 05:49:10 bkinman, i think there's a menuconfig task you can run Jul 09 05:51:25 bkinman: "doesnt work"? Jul 09 05:52:00 kergoth: Sorry, i should be more pedantic. ERROR: Task do_config does not exist for target virtual/kernel Jul 09 05:52:08 it's configure, not config Jul 09 05:52:26 and it's not about being pedantic, it's about giving us actual useful information Jul 09 05:52:33 if there's an error, give us the error Jul 09 05:53:59 For sure. It's working, thanks. Jul 09 05:54:17 03Khem Raj  07org.openembedded.dev * r17da1f1387 10openembedded.git/recipes/dosfstools/ (dosfstools_2.11.bb dosfstools_3.0.9.bb): Jul 09 05:54:17 dosfstools: Add recipe for 3.0.9 and fix large file support. Jul 09 05:54:17 * Pass -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 if large file support Jul 09 05:54:17 supported. Jul 09 05:54:17 Signed-off-by: Khem Raj Jul 09 05:54:32 np Jul 09 05:55:33 gm Jul 09 05:55:38 hey eFfeM Jul 09 06:53:44 khem, you still there? I was wondering if gmp should not be a dependency for gcc-cross (just like glibc is) Jul 09 06:55:43 eFfeM, it should be, yeah. What pulls it in for gcc-cross to use? Jul 09 06:57:25 grg, currently (fresh build) I see that after building gcc-cross that gmp-native is build but gmp isn't Jul 09 06:58:14 but I am not an expert on crossbuilding gcc Jul 09 06:58:26 eFfeM, actually, now that you mention that, it sounds right. Jul 09 06:58:49 grg, clarify "it" Jul 09 06:59:28 the gcc cross compiler will use libgmp (gmp-native), but it wont link applications that it builds with gmp (unless of course, you specify -lgmp) Jul 09 07:00:04 so ldd on the gcc cross compiler will show libgmp Jul 09 07:00:08 grg when compiling the target libs internal in gcc, it will pass -I${GMPINC} which points to a host dir causing the system to pick up a faulty include for me Jul 09 07:01:28 03Koen Kooi  07org.openembedded.dev * rb0773cc546 10openembedded.git/recipes/gnome/gedit_2.30.0.bb: gedit 2.30.0: bump PR Jul 09 07:02:28 eFfeM, i'm not sure i understand what is happening. Got a log snippet you can paste somewhere? Jul 09 07:03:59 mickey|office: do you know if the smtp listener on ltg is stopped for some deliberate reason? Jul 09 07:04:05 if not, I will restart it Jul 09 07:04:55 no deliberate reason i can think of Jul 09 07:05:34 grg, don't really have a good snippet to paste but what is happening is that whencompiling libgcc.a there is a -I${GMPINC} in the compile line, this inc points to tmp/sysroots/i686-linux/usr/include which contains native .h files causing (on my system) the build of libgcc.a to fail (because it picks up the wrong unistd.h) Jul 09 07:06:16 hm, looks like florian might have done that. I guess I will ask him. Jul 09 07:06:27 grg, let me pastebin the offending cmd Jul 09 07:07:05 eFfeM, i suspect khem really is the person you want to talk to about that :) Jul 09 07:08:03 grg: http://www.pastebin.ca/1897111 Jul 09 07:08:31 grg, i know, but our hours don't overlap too much and khem is quite loaded with work Jul 09 07:11:33 eFfeM, gcc-4.1.2.inc has gmp in DEPENDS. Jul 09 07:13:07 hm, yes you're right, overlooked that one Jul 09 07:13:41 but I fear that gcc-cross is considered as a native recipe Jul 09 07:21:10 hi Jul 09 07:22:14 gm hrw Jul 09 07:27:29 03Koen Kooi  07org.openembedded.dev * recb65418ee 10openembedded.git/recipes/sqlite/sqlite3_3.6.23.1.bb: sqlite3: add 3.6.23.1 Jul 09 07:27:40 eFfeM, i'm not sure how to easily resolve that without looking at how libgcc.a is built... Jul 09 07:28:03 eFfeM, presumably you do want to -I${GMPINC} for some things, but not for others? Jul 09 07:32:42 eFfeM, you could see if you can find another gcc version that does build for you (i know, you only have one version for nios2, but try a different arch) and see how that does things differently Jul 09 07:32:48 home time for me... Jul 09 07:32:54 bye Jul 09 07:52:45 Hi all, i'm pretty new to OE and i'm trying to build a rootfs (base-image). This morning i saw that libpam failed to unpack. (see http://pastebin.com/tiUpsX0s) Jul 09 07:52:51 03Koen Kooi  07org.openembedded.dev * r070337d3dd 10openembedded.git/recipes/mozilla/ (16 files in 2 dirs): firefox: replace 3.6.4 with 3.6.6 Jul 09 07:53:02 It seems that it's trying to unpack sources in / Jul 09 07:54:46 I already met such a problem with another paquet. I solved it following instructions from a forum Jul 09 07:55:15 The trick was to write file:/// instead of file:// Jul 09 07:55:36 but this time i dont know what to do Jul 09 08:04:05 good morning Jul 09 08:05:41 hi Jul 09 08:14:54 03Koen Kooi  07org.openembedded.dev * rf916c34708 10openembedded.git/ (2 files in 2 dirs): linux-omap-psp 2.6.32: turn on oprofile for dm3730-am3715-evm Jul 09 08:22:19 florian: good morning Jul 09 08:23:13 good morning! Jul 09 08:23:29 florian: is it intentional that ltg is not running an smtp listener at the moment? it looks like maybe you stopped it last night. Jul 09 08:25:10 pb__: yes that's true, I forgot to start it after the mailman update Jul 09 08:25:15 fixed Jul 09 08:25:18 ~lart me Jul 09 08:25:19 * ibot drops a humongous exploding nuke on florian Jul 09 08:25:28 :( Jul 09 08:29:52 morning Jul 09 08:30:59 florian: btw, it seems that current LTG crew will never fix dns and wiki.. how can I do it? :) Jul 09 08:32:29 Jay7: what is wrong with it? Jul 09 08:32:37 fwiw, oe dns is not hosted at ltg Jul 09 08:33:19 pb__: I mean LTG projects part Jul 09 08:33:46 Jay7: Basically ltg is a community prject and who ever wants to help is welcome. The master of dns is Nils currently. It might be a good idea to drop him a mail and I'll kick him here locally :) Jul 09 08:34:33 pb__: We are still lacking some entries incuding a default catch-all for all the *projects vhosts. Jul 09 08:34:59 ah, I see Jul 09 08:35:07 Jay7: but what's wrong with the wiki? Jul 09 08:35:21 03Henning Heinold  07org.openembedded.dev * r9ec3af92cf 10openembedded.git/recipes/gcc/ (12 files in 9 dirs): Jul 09 08:35:21 gcc: add support for builtin gcc-atomics for gcc-4.3.x versions Jul 09 08:35:21 * bump all INC_PR's Jul 09 08:35:27 florian: thanks, smtp works again Jul 09 08:35:54 * florian kicks the queue one more time to get some mails out Jul 09 08:37:13 florian: http://projects.linuxtogo.org/plugins/mediawiki/index.php?group_id=50 Jul 09 08:37:24 page not found :) Jul 09 08:38:15 ok... mediawiki plugin... wait Jul 09 08:38:27 ko Jul 09 08:38:28 * Jay7 just want fine working kexecboot site :) Jul 09 08:39:06 gcc atomics pushed Jul 09 08:39:37 morning wog Jul 09 08:40:24 Jay7: this is supposed to be installed but the package with the plugin is broken Jul 09 08:40:52 florian: is it recoverable? :) Jul 09 08:41:37 Jay7: I think so... the Fusionforge package for Lenny depends on a version of mediawiki that is not available in Lenny. Jul 09 08:44:09 Hi all. Could someone explain to me why, some times, OE try to unpack sources or create files in '/' ? ( see http://pastebin.com/tiUpsX0s) Jul 09 08:46:11 kerloi: looking as misconfiguration Jul 09 08:46:45 check your local.conf and env setup script for path with '../' Jul 09 08:46:50 mm, I'm building a console-image for machine=x86, I don't think it's normal that this is building vlc, xbmc, is it? (http://pastebin.com/iCVdDLWf) Jul 09 08:47:17 hi blindman Jul 09 08:47:42 tsjsieb: it may be required by bluez -> gstream -> etc.. Jul 09 08:47:53 tsjieb vlc and xmbc not Jul 09 08:48:06 but gstreamer because of bluez-sound Jul 09 08:48:20 and gstreamer needs gnome-vfs Jul 09 08:48:26 so its building halfe of gnome Jul 09 08:48:26 whats the best way to find why xbmc and vlc are build? Jul 09 08:48:35 Jay7: ok i'll check Jul 09 08:48:45 bitbake -g console-image Jul 09 08:49:03 o.k. thanx Jul 09 08:50:45 Jay7: i haven't found any '../' in all conf files i have Jul 09 08:51:46 kerloi: hm.. then it may be wrong recipe.. there was some changes around pam Jul 09 08:52:02 git pull and complain again :) Jul 09 08:52:06 Jay7: i used to have a similar problem with glibc two days ago ( http://article.gmane.org/gmane.comp.handhelds.openembedded/34105 ) Jul 09 08:52:27 Jay7: ok Jul 09 08:52:36 this was discussed here iirc Jul 09 08:52:44 about /ld.so.conf Jul 09 08:53:40 Jay7: I've fixed it by writting file:/// instead of file:// in the recipe Jul 09 08:53:59 But this is an ugly hack Jul 09 08:56:02 By the way i'm using OE since monday so i'm not really an expert. Jul 09 08:56:57 This patch is attached to the related thread, but it looks weird (especially at the end) : http://patchwork.openembedded.org/patch/2320/ Jul 09 09:11:17 florian: I'll send mail to Nils this evening Jul 09 09:11:19 should go now Jul 09 09:34:19 stupid Q, aren-t -I dirs supposed to be visited in the order they appear? Jul 09 09:35:01 (not talking about -isystem, I know these are later) Jul 09 09:35:26 effem hm there is no safe guard Jul 09 09:35:44 gcc complains if it founds something doubled Jul 09 09:35:50 **** (curse removed) Jul 09 09:36:19 it complains if a name is twice, but not if a file is twice, I expected it to pick the first one Jul 09 09:39:20 actually learned now that a -I of a std sys inc dir is ignored, Jul 09 09:39:43 it is picked up at the end anyway, so no way to force the dir is searched before Jul 09 09:40:56 woglinde: is 'dot depends.dot -Tpdf -ofile depends.pdf' the right way to get a graph from the output? (as my computer is running +/- 15 minutes on that command already :P) Jul 09 09:41:30 tsjsieb no the graphs are to big Jul 09 09:41:42 but they are in human readable form Jul 09 09:41:49 do the search manually Jul 09 09:42:16 o.k. thanks that saves me some waiting Jul 09 09:43:09 khem, please sed -i -e s/nneds/needs/g $(git grep -l nneds) Jul 09 09:43:21 TIA Jul 09 09:48:36 mm, both vlc and xbmc are indeed pulled by gst-plugins, which is pulled in by bluez4, wich is pulled in by 'task-base'bluetooth' strange thing is that x86.conf doesn't state bluetooth in it's machine_features Jul 09 09:49:02 uh why gst-plugin pulls in vlc Jul 09 09:49:08 should be the otherway round Jul 09 09:49:21 hm let me see Jul 09 09:50:04 actually gst-plugins are pullint x264, which is receipe in vlc directory Jul 09 09:50:37 hm Jul 09 09:50:53 because a recipe is in a dir Jul 09 09:50:56 means nothing Jul 09 09:51:46 sorry that's my mistake, it's not actually building vlc and xbmc I see now Jul 09 09:51:53 which gst-plugin? Jul 09 09:52:54 only x264_r2245.bb and libmms_0.5.bb Jul 09 09:58:08 woglinde: http://pastebin.com/SXcLX0s1 Jul 09 10:12:42 git-native packaged-stage fails, I think I've ssen this before, is there a fix for it ? Jul 09 10:13:29 actaually stoppign the build and restarting it fixes it, but that is not toonice Jul 09 10:19:32 ah, I now see that task-base-bluetooth is not depending on machine-features, but is always pulled. Jul 09 10:20:52 re Jul 09 10:20:57 tsjsieb yes Jul 09 10:21:01 thats what we told you Jul 09 10:21:16 building != installing Jul 09 10:33:44 03Robert Schuster  07org.openembedded.dev * r136e6c244f 10openembedded.git/recipes/icedtea/icedtea6-native_1.8.bb: icedtea6-native 1.8: Added comment. Jul 09 10:37:20 hi Jul 09 10:38:16 hi Jul 09 10:40:01 I got an error with lsof_4.83.bb -> http://pastebin.com/XfzKVwGC Jul 09 10:43:14 seems that the tar in the tar.bz2 doesn't get extracted Jul 09 10:46:42 somebody knows touchscreen god who can help with this? I think I need to patch ts driver: http://bugs.openembedded.org/show_bug.cgi?id=5449 Jul 09 10:46:49 hi Jul 09 10:47:50 geo_gcju: maybe yome hickup? bitbake -c clean lsof; bitbake lsof Jul 09 10:53:08 dcordes: yep, I'm on it, doing some printf-debugging with bb.note Jul 09 10:54:20 hi raster Jul 09 10:54:47 03Koen Kooi  07org.openembedded.dev * rea51e1d4a7 10openembedded.git/recipes/openjdk/openjdk-6-common.inc: openjdk: bump PR to force rebuild against updated gcc Jul 09 10:57:10 okay, for now I just tar xf the tar inside the tmp directory Jul 09 10:57:17 and move it one dir up Jul 09 10:57:39 sth. is wrong with the python do_unpack () function, at least with my setup Jul 09 11:14:56 How should I go about changing kernel configuration and rebuilding it and deploying it on the target ? Jul 09 11:15:23 My best guess is to a devshell, menuconfig, exit out and bitbake and then install the kernel ipk and modules Jul 09 11:15:31 screwgoth1: bitbake -c menuconfig virtual/kernel; bitbake virtual/kernel Jul 09 11:15:59 eFfeM: virtual/kernel ? Jul 09 11:16:53 yes Jul 09 11:17:15 that'll resovle to your actual kernel recipe Jul 09 11:19:12 you might want to save your .config to a more persistent place if you want to redo this later Jul 09 11:21:06 eFfeM: ok .. but it will rebuild the kernel and make a uImage in the tmp/deploy/.../images/ folder ? Jul 09 11:21:39 yes, the 2nd bitbake will Jul 09 11:21:54 give it a try :-) Jul 09 11:26:20 sounds like fun .. i am trying as we type ... thanks :-) Jul 09 11:27:23 Another quick question, I have updated/added a few recipes for my development ... How do I submit the same back to the project ? Jul 09 11:27:29 send a patch on the devel list ? Jul 09 11:28:29 eFfeM : Hey wait !! bitbake -c menuconfig virtual/kernel did not let me change the config options. Jul 09 11:38:47 screwgoth1: wrt patches: yes please, send them to the list, it is very preferred if they are from git commits (use git format-patch and git send-email) Jul 09 11:39:18 wrt menuconfig: did you get a new screen with the menu interface ? Jul 09 11:42:15 eFfeM: nope ... I was expecting that .. I did not want some modules to be in-built in the kernel Jul 09 11:45:54 eFfeM: My bad !! The menu interface just popped up. awesomenesss.... Jul 09 11:57:33 ok, good Jul 09 11:57:48 no idea why it takes so long, guess it had to compile lots of other things first Jul 09 12:04:02 hi JaMa Jul 09 12:08:21 GNUtoo|laptop: hi.. feel free to fix "enabled" issue Jul 09 12:09:45 JaMa, ok, what's the best way to fix it? is ENABLE_BINARY_LOCALE_GENERATION only 0 or 1 ? Jul 09 12:11:53 who knows well bitbake btw Jul 09 12:11:54 ? Jul 09 12:16:29 GNUtoo|laptop: what about "not enabled or enabled == 0"? Jul 09 12:16:41 that's what I tought Jul 09 12:16:53 other parts need fixing too Jul 09 12:17:01 there are other if not something Jul 09 12:17:27 but I wondered if such thing could exist Jul 09 12:17:33 ENABLE_BINARY_LOCALE_GENERATION = "False" Jul 09 12:17:39 I never heard of it tough Jul 09 12:17:43 GNUtoo|laptop: remaining ifs are ok Jul 09 12:17:50 ah ok Jul 09 12:17:50 hi stefan Jul 09 12:18:42 btw I must workarround that: Jul 09 12:18:43 NOTE: Task failed: Unknown fetch Error: [Errno 2] No such file or directory: '/home/gnutoo/embedded/oe/sources/git_gitorious.org.htc-msm-2-6-32.leviathan-incoming.git_3a5d683e5893ae75ace4bdfef4f5605555d40740.tar.gz' Jul 09 12:18:45 any ideas Jul 09 12:18:46 ? Jul 09 12:18:51 hm lsof is broken yes Jul 09 12:19:13 it's in bitbake fetcher or git fetcher Jul 09 12:19:28 GNUtoo|laptop: glibc/glibc-package.inc is using "if enabled and int(enabled):" Jul 09 12:19:28 but I'm not familiar with that part at all Jul 09 12:19:34 GNUtoo|laptop: did you try http now? Jul 09 12:19:53 leviathan, it doesn't change that error Jul 09 12:20:17 http for the part where it really fetch Jul 09 12:20:28 not for when it think it already fetched Jul 09 12:20:32 hi Jul 09 12:20:35 hi woglinde Jul 09 12:20:36 hi all Jul 09 12:21:06 perl-native do_compile : No Makefile ?! I get this with both perl-native recipes http://privatepaste.com/16a8c33d4d Jul 09 12:21:10 any idea ? Jul 09 12:21:46 JaMa, thanks I'll do that but I can't test now because of this fetcher issue Jul 09 12:22:27 dcordes_, maybe look at the permissions denied? Jul 09 12:23:21 GNUtoo|laptop: aha. I saw this error before on this machine Jul 09 12:23:39 I had one permission denied too but it continued so.... Jul 09 12:23:50 but I don't remember the recipe/package Jul 09 12:24:10 who knows bitbake? Jul 09 12:25:44 hi RP Jul 09 12:33:12 GNUtoo|laptop: hmm Jul 09 12:33:13 GNUtoo|laptop: if you have git_gitorious.org.htc-msm-2-6-32.leviathan-incoming.git_3a5d683e5893ae75ace4bdfef4f5605555d40740.tar.gz.md5 and not that file, remove .md5 Jul 09 12:33:38 JaMa, I've only the lock file Jul 09 12:33:46 GNUtoo|laptop: you could overwrite the checkout function in the recipe :-) Jul 09 12:34:25 leviathan, that won't help me fix the real-fetching gitorious thing Jul 09 12:34:37 GNUtoo|laptop: me too.. also timeouted for me when I was downloading all OE sources.. Jul 09 12:35:26 I remove the lock and retry Jul 09 12:35:37 hmm Jul 09 12:36:30 I'll also make some bitbake changes Jul 09 12:37:18 * JaMa trying to checkout 636fa4daf243826ef6cebb64dd0509f3b079fcb5 Jul 09 12:37:26 fatal: The remote end hung up unexpectedly Jul 09 12:37:26 fatal: early EOF Jul 09 12:37:33 so it's the same as before Jul 09 12:44:58 ok Jul 09 12:45:15 bye Jul 09 12:45:41 GNUtoo|laptop: http://paste.pocoo.org/show/235458/ Jul 09 12:45:53 GNUtoo|laptop: works for me :) Jul 09 12:46:44 hmm partially :/ Jul 09 12:46:48 JaMa, thanks a lot!!! please send the patch upstream Jul 09 12:46:50 ah ok Jul 09 12:47:36 GNUtoo|laptop: it works only if SRCREV == HEAD :/ Jul 09 12:47:57 GNUtoo|laptop: otherwise you will get " fatal: failed to unpack tree object 636fa4daf243826ef6cebb64dd0509f3b079fcb5" :( Jul 09 12:48:03 ah ok Jul 09 12:48:25 I can't debug it because of the no such file... Jul 09 12:48:30 too bad Jul 09 12:48:40 according to mickey|office it should be some variables Jul 09 12:48:49 because running the command manually works Jul 09 12:49:51 like some variable lacking Jul 09 12:49:58 or some variables that are too much Jul 09 12:50:05 I thought of the LANG,LC etc... Jul 09 12:50:08 but no luck Jul 09 12:50:45 for me the command manully fails the same as running it from bitbake.. Jul 09 12:51:14 ah ok nice Jul 09 12:51:40 so it's easier to debug Jul 09 12:56:41 JaMa, at what point does it fail? Jul 09 12:56:47 fetching? Jul 09 12:56:54 after fetching? Jul 09 12:57:11 did you try GIT_TRACE=1 ? Jul 09 12:58:33 GNUtoo|laptop: try manually git clone -n git://gitorious.org/htc-msm-2-6-32/leviathan-incoming.git /OE/downloads/git/gitorious.org.htc-msm-2-6-32.leviathan-incoming.git Jul 09 12:58:57 GNUtoo|laptop: that's exactly what bitbake calls and fails Jul 09 12:59:05 ok Jul 09 12:59:22 with my distro's git or oe's git? Jul 09 12:59:27 GNUtoo|laptop: and then you can try it with "bitbake env" export HOME="/OE"; export PATH="/OE/tmpdir-dev/sysroots/x86_64-linux/usr/bin/spitz-angstrom-linux-gnueabi:/OE/tmpdir-dev/sysroots/x86_64-linux/usr/bin/armv5te-angstrom-linux-gnueabi:/OE/tmpdir-dev/sysroots/x86_64-linux/usr/sbin:/OE/tmpdir-dev/sysroots/x86_64-linux/usr/bin:/OE/tmpdir-dev/cross/armv5te//bin:/OE/tmpdir-dev/sysroots/x86_64-linux/sbin:/OE/tmpdir-dev/sysroots/x86_64-linux/bin:/OE/tmpdir Jul 09 13:00:00 GNUtoo|laptop: distro's git in first case, OE git in second (due to PATH export) Jul 09 13:00:07 ok Jul 09 13:00:29 GNUtoo|laptop: and of course update paths to your coresponding paths Jul 09 13:01:02 of course Jul 09 13:01:04 * JaMa received new Core i5 with 8G ram and ssd :) Jul 09 13:01:09 wow Jul 09 13:01:18 I've core i7 with 4GB ram Jul 09 13:01:28 I think the ram is the bottleneck Jul 09 13:03:40 JaMa, when does it fail? Jul 09 13:03:48 at receiving objects? Jul 09 13:03:51 here is the bottleneck the OS.. windows7 Jul 09 13:03:52 at what percentage? Jul 09 13:03:55 ouhc Jul 09 13:04:14 ah it's a work computer? Jul 09 13:04:31 now with git from distro it seems to work sofar Resolving deltas: 31 Jul 09 13:04:39 ok Jul 09 13:04:45 GNUtoo|laptop: yes work computer, at home I have Phenom II + 4GB Jul 09 13:04:51 ok nice Jul 09 13:05:26 deltas resolved ok.. done Jul 09 13:05:31 ok Jul 09 13:05:45 maybe for the os bottleneck : use an external hdd or something like that? Jul 09 13:06:10 hmm now also oe git seems to work, strange Jul 09 13:06:21 ah Jul 09 13:06:25 hmmm Jul 09 13:06:36 maybe because you made it work with the os's git first Jul 09 13:06:43 then it passed the failure point Jul 09 13:06:49 and then it works with oe's git Jul 09 13:07:31 GNUtoo|laptop: no I've removed created checkout first Jul 09 13:07:39 ok Jul 09 13:12:13 -c fetch done Jul 09 13:12:27 I can give you checkouts if you still cannot clone it even manually Jul 09 13:13:32 ok Jul 09 13:13:35 1s bbs Jul 09 13:14:51 GNUtoo : weird - clone via http://git.gitorius works for me, but git://gitorious always fails Jul 09 13:18:31 back Jul 09 13:18:41 zenob_, ok Jul 09 13:19:02 maybe we should switch to http instead Jul 09 13:19:07 but what's the syntaz? Jul 09 13:19:10 *syntax Jul 09 13:19:26 http://;proto=git or git://;proto=http Jul 09 13:20:35 i've tried both but still nothing Jul 09 13:20:41 ok Jul 09 13:21:06 zenob_, what did you run when telling me that: Jul 09 13:21:08 GNUtoo : weird - clone via http://git.gitorius works for me, but git://gitorious always fails Jul 09 13:21:37 git clone ... ? Jul 09 13:21:51 ah ok Jul 09 13:21:56 so you can clone manually Jul 09 13:21:58 and it fails Jul 09 13:22:24 yes Jul 09 13:22:32 ok what's the exact command? Jul 09 13:22:51 I wasn't able to make it fail while cloning manually Jul 09 13:22:54 for instance: Jul 09 13:23:08 git clone -n git://gitorious.org/htc-msm-2-6-32/leviathan-incoming.git works Jul 09 13:23:23 yes Jul 09 13:23:57 git://...;proto=http is right syntax Jul 09 13:23:58 i've tried many times, but always hungs when fetching objects and throws EOF.... Jul 09 13:24:57 zenob_, ok Jul 09 13:26:48 zenob_, ok so it's during the "Receiving objects" ? Jul 09 13:26:58 yes Jul 09 13:27:02 ok thanks Jul 09 13:27:06 at what % Jul 09 13:27:07 ? Jul 09 13:27:34 15% Jul 09 13:27:59 gm Jul 09 13:28:48 03Frans Meulenbroeks  07org.openembedded.dev * rb364659466 10openembedded.git/recipes/linux-libc-headers/linux-libc-headers_2.6.34.bb: Jul 09 13:28:49 linux-libc-headers_2.6.34.bb: added checksums for non nios version Jul 09 13:28:49 and fixed ${S} for non nios (needed for -native) Jul 09 13:28:49 Signed-off-by: Frans Meulenbroeks Jul 09 13:28:54 hi likewise Jul 09 13:29:17 already tried to build a nios2 image ? Jul 09 13:30:18 eFfeM: nope, but about to do so before monday Jul 09 13:30:31 cool Jul 09 13:34:33 ok thanks Jul 09 13:38:29 JaMa, zenob_ in devshell git fetch correctly Jul 09 13:57:17 is there some command that clear all environment variables Jul 09 13:57:25 so I could try git clone Jul 09 14:12:10 zenob_, it always fails at 15%? Jul 09 14:13:00 JaMa, do you have the exact full command ran by oe? Jul 09 14:14:08 GNUtoo|laptop: I pasted it here.. Jul 09 14:15:01 so you modified the command? Jul 09 14:15:29 because there was a lot more arguments Jul 09 14:15:41 and some more exports Jul 09 14:15:44 originally Jul 09 14:16:56 GNUtoo|laptop: and it was created by this patch http://paste.pocoo.org/show/235506/ Jul 09 14:17:42 GNUtoo|laptop: those exports are probably part of basecmd Jul 09 14:17:47 ok Jul 09 14:18:05 because of my file error I can't have the command Jul 09 14:18:34 I just tried removing all export from a normal shell and it fetched ok Jul 09 14:18:36 so not that Jul 09 14:18:52 maybe I'll try some python command Jul 09 14:20:34 try it with this patch, that "No such file" error should be _after_ git clone Jul 09 14:51:44 GNUtoo, no, it fails at different values Jul 09 14:52:10 but i've changed protocol to http and now it works Jul 09 15:04:34 03Frans Meulenbroeks  07org.openembedded.dev * r1620c1459b 10openembedded.git/recipes/busybox/ (busybox-1.14.3/fdisk_nios2.patch busybox_1.14.3.bb): Jul 09 15:04:34 busybox 1.14.3: added a defined(__nios2__) Jul 09 15:04:34 Signed-off-by: Frans Meulenbroeks Jul 09 15:10:53 03Frans Meulenbroeks  07org.openembedded.dev * r5a0e69c2f1 10openembedded.git/recipes/busybox/ (busybox-1.15.3/fdisk_nios2.patch busybox_1.15.3.bb): Jul 09 15:10:53 busybox_1.15.3: added a defined(__nios2__) Jul 09 15:10:53 (actually as there were two entries for __s390__ hijacked one of it Jul 09 15:10:53 Signed-off-by: Frans Meulenbroeks Jul 09 15:14:40 03Frans Meulenbroeks  07org.openembedded.dev * reb751a519b 10openembedded.git/recipes/busybox/ (busybox-1.16.2/fdisk_nios2.patch busybox_1.16.2.bb): Jul 09 15:14:40 busybox 1.16.2: added a defined(__nios2__) Jul 09 15:14:40 (actually as there were two entries for __s390__ hijacked one of it Jul 09 15:14:40 Signed-off-by: Frans Meulenbroeks Jul 09 15:55:57 morning Jul 09 15:57:29 g'day kergoth Jul 09 16:24:33 03Frans Meulenbroeks  07org.openembedded.dev * r97d368012f 10openembedded.git/recipes/binutils/ (3 files in 2 dirs): Jul 09 16:24:33 binutils 2.20.1: added patches to support nios2 Jul 09 16:24:33 Signed-off-by: Frans Meulenbroeks Jul 09 16:28:18 has there been a patch recently that turns patches into symlinks instead of coying them? Jul 09 16:28:54 eFfeM: yes, I think khem did that Jul 09 16:30:34 hm, can't seem to find the patch and apparently quilt is not too happy with the symlinks Jul 09 16:31:10 if a patch fails I normally do a quilt push -f ; then fix and refresh but now quilt tells me there is only garbage in the patch and refresh does not work either Jul 09 16:34:57 zecke any idea whihc file this is in? can't find it by commit msg Jul 09 16:46:08 anyone seen libtool failing to install this way? http://pastebin.com/nsC79yjH Jul 09 16:47:27 no idea why it complains when it should install right into this dir Jul 09 17:26:10 can anyone help a newb? Jul 09 17:28:47 I know I'm missing something that should be obvious, trying to get grub baked into my angstrom image Jul 09 17:32:42 should I ask in #angstrom ? Jul 09 17:33:16 karmakop: maybe post the error? Put it on pastebin and post a link here Jul 09 17:33:37 no error Jul 09 17:33:50 image builds but doesn't have the grub files as far as I can tell Jul 09 17:34:55 hmm Jul 09 17:35:13 karmakop: nothing in tmp/deploy...images? Jul 09 17:36:57 I have images in the tmp/deploy Jul 09 17:37:24 when I mount the images I don't see the grub binaries in /sbin Jul 09 17:37:52 karmakop: hmm, no idea then Jul 09 17:38:04 karmakop: I never compiled grub with OE Jul 09 17:38:28 not in /usr/sbin either Jul 09 17:38:45 I tried adding the following to my local.conf Jul 09 17:38:49 DISTRO = "angstrom-2008.1" Jul 09 17:38:49 DISTRO_EXTRA_RDEPENDS += "grub" Jul 09 17:39:20 I know it isn't the best way but was going to try the other methods after I got by this problem Jul 09 17:39:54 np Jul 09 19:01:40 eFfeM_work: I have a patch for quilt-native Jul 09 19:01:55 eFfeM_work: which will let you refresh the patches on the symlinks Jul 09 19:25:44 03Khem Raj  07org.openembedded.dev * r2f5f667052 10openembedded.git/recipes/uclibc/uclibc_git.bb: Jul 09 19:25:44 uclibc_git.bb: Bump to tip of git. Jul 09 19:25:44 Signed-off-by: Khem Raj Jul 09 19:25:54 03Khem Raj  07org.openembedded.dev * rf04e9d5546 10openembedded.git/recipes/krb/krb5_1.6.3.bb: Jul 09 19:25:55 krb5_1.6.3.bb: copyperms.patch is applied manually so add apply=no Jul 09 19:25:55 Signed-off-by: Khem Raj Jul 09 19:30:57 03Khem Raj  07org.openembedded.dev * rbd1a21b615 10openembedded.git/recipes/binutils/binutils_2.20.1.bb: Jul 09 19:30:58 binutils_2.20.1.bb: Remove redundantly added patch=1 its not needed anymore Jul 09 19:30:58 Signed-off-by: Khem Raj Jul 09 19:35:13 03Stanislav Brabec  07org.openembedded.dev * r15b7c63694 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.net:openembedded into org.openembedded.dev Jul 09 19:35:14 03Stanislav Brabec  07org.openembedded.dev * rb6738f4553 10openembedded.git/recipes/gtk+/ (6 files in 2 dirs): gtk+: Update to version 2.20.1 + fix of midori DnD grab freeze (GNOME#623865). Jul 09 19:35:15 03Stanislav Brabec  07org.openembedded.dev * r211fb05d66 10openembedded.git/recipes/glib-2.0/ (9 files in 2 dirs): glib-2.0: Update to version 2.24.1. 4 bug fixes, 2 of them were included as patches. Jul 09 19:49:14 hmm when will people start using git rebase Jul 09 19:49:50 03Khem Raj  07org.openembedded.dev * r3382da9830 10openembedded.git/docs/usermanual/ (3 files in 3 dirs): Jul 09 19:49:51 usermanual: Updates to reflect changes in file:// treatment for patches. Jul 09 19:49:51 Signed-off-by: Khem Raj Jul 09 19:50:13 khem: You mean the merges? Jul 09 19:50:18 yesss Jul 09 19:50:32 pushing crap into public repo is non sense Jul 09 19:50:39 I often forget about pull --rebase as well :) Jul 09 19:50:58 But I normally have different branches and cherry-pick into master anyway Jul 09 19:51:11 I would propose a pull model Jul 09 19:51:13 for OE Jul 09 19:52:13 khem: The problem I see with this is that we don't have the benevolved dictator and his subsystem maintainers here Jul 09 19:52:25 we are lacking man power :( Jul 09 19:52:47 khem: Other then that I very much agree with the pull model Jul 09 19:53:16 khem: still someone needs to have the hat with integrate all the stuff and make sure it holds together Jul 09 19:55:00 hmm, I still don't get what the problem from libtool is Jul 09 19:55:04 stefan_schmidt: btw your libtool woes could be related to http://www.mail-archive.com/libtool@gnu.org/msg09027.html Jul 09 19:55:14 http://pastebin.com/nsC79yjH Jul 09 19:55:22 stefan_schmidt: I can do that Jul 09 19:55:24 The path ends as it should and still it complains Jul 09 19:55:35 I do that 90% of the time anyway Jul 09 19:55:46 khem: you have the time? Jul 09 19:55:46 fixing other peoples patches :) Jul 09 19:55:53 heh Jul 09 19:55:56 stefan_schmidt: in whatever time I have Jul 09 19:56:08 atleast then I will do it for a purpose Jul 09 19:56:28 right now I have to get one thing working but I need to fix 10 before I can get to where I want Jul 09 19:57:35 khem: hmm, the problem is that OE has so much meta data for different combinations Jul 09 19:57:49 I mean is someone building gnome things with uclibs on mips Jul 09 19:57:59 or efl on powerpc Jul 09 19:58:11 yeah Jul 09 19:58:20 but we could have some buildbots Jul 09 19:58:23 stuff like this breaks if no one is "responsible" Jul 09 19:58:40 and nothing gets pushed before build is done for some arches Jul 09 19:58:44 right now we have nothing Jul 09 19:59:05 at bugalbs we are using buildbot heavily (still from hrw|gone time there) Jul 09 19:59:15 But we are using it to build _after_ the commit Jul 09 19:59:26 I think devs with commit access bear responsibility to keep it in good shape not commit whatever they wish Jul 09 19:59:33 better the nothing put it would be great to have it before the commit hits the repo Jul 09 19:59:52 khem: indeed, that is part of the problem Jul 09 20:00:00 yes thats why something like staging branch Jul 09 20:00:04 all commits gothere Jul 09 20:00:09 and get sanitized Jul 09 20:00:40 I get frustrated that I never can get to the thing that I wanted to use OE for Jul 09 20:00:46 I am in myriad of making it work Jul 09 20:00:54 thats counter productive Jul 09 20:01:16 khem: what about unstable -> testing -> stable? Jul 09 20:01:30 yes that would be nice Jul 09 20:01:34 actually Jul 09 20:01:48 we somehow had something like this in OM. But zecke should know more about it. He was holding the stuff together for one release Jul 09 20:01:50 actually we dont need unstable Jul 09 20:02:23 and we should aim for some sort of time based releases Jul 09 20:02:38 otherwise projects never get used Jul 09 20:02:44 khem: the main point I would see in unstable would that the moving from unstable to testing could get automated after the buoldbots past all tests Jul 09 20:02:57 oh i see Jul 09 20:02:59 makes sense Jul 09 20:03:28 I think we need more participation for companies using OE Jul 09 20:03:36 atleast infrastructure wise Jul 09 20:03:46 khem: What are you thinking about? Jul 09 20:03:48 I can not test all combo on my poor laptop Jul 09 20:04:00 khem: At buglabs we like to have a goof relationship to OE Jul 09 20:04:17 thats good and I recognise that Jul 09 20:04:18 depending on the needs I could ask Jul 09 20:04:30 but there are many others who could help with resources Jul 09 20:04:39 So you are thinking of a big machine for buildbot runs? Jul 09 20:04:44 * Jay7 have note in TODO to setup tinderbox for OE on new server Jul 09 20:04:54 Jay7: :) Jul 09 20:05:08 yes. Something like building for qemuarm qemumips qemuppc qemux86 everyday Jul 09 20:05:16 I'll do build periodically angstrom for zauruses Jul 09 20:05:41 and may be make x11-image or something which covers quite a bit of recipes Jul 09 20:06:08 ideally bitbake world would be great but it does not work atm Jul 09 20:06:10 freebsd project doing periodical builds of all ports tree Jul 09 20:06:21 although we could revive it with some efforts Jul 09 20:06:22 khem: internally we have a 8 core i7 beast with 12GB ram. Thats of course a but expensive to get sponsored Jul 09 20:06:34 heh Jul 09 20:06:47 Hmm Jul 09 20:07:09 * Jay7 will buy Phenom II X6 with 4-8Gb Jul 09 20:07:12 I think I can say this, matching engineering wants to a corporate budget requires fineese :) Jul 09 20:07:45 but I agree, I would love to have better tests before something hit the repo and time based releases would be a dream Jul 09 20:07:50 Tartarus: :) Jul 09 20:07:52 * nitin is back from lunch Jul 09 20:08:55 Tartarus: well engineers should convince there money bosses why it is good to donate some resources for nothing Jul 09 20:08:59 its like planting Jul 09 20:09:23 Like I said, it takes finesse Jul 09 20:09:29 * jconnolly just tried bitbake world Jul 09 20:09:33 and not planting a apple tree which will bear fruits in 5 years but something like a vegetable Jul 09 20:10:17 khem: I have a RFC on my disk for a new stable branch :) Jul 09 20:10:24 Should send it out tomorrow Jul 09 20:10:48 it feels to much diverged from dev to stable/2009 Jul 09 20:10:50 stefan_schmidt: ok Jul 09 20:11:06 and we should remove non building recipes Jul 09 20:11:14 or fix them Jul 09 20:12:05 khem: I could live with this. But sometimes they are only buildable in a special combination of distro, TARGET_ARCH, etc Jul 09 20:12:07 hard to tell Jul 09 20:12:16 I have learned so many companies in bay are leech OE but they dont even let their employees to be on oe ml Jul 09 20:12:21 but some are obviously broken :) Jul 09 20:12:25 because they will waste their time Jul 09 20:12:34 uh, thats bad Jul 09 20:12:49 bay area is west coast? Jul 09 20:12:53 yes Jul 09 20:12:57 ok Jul 09 20:13:02 khem: can we collect that companies and send there some "open letter from OE e.V."? Jul 09 20:13:15 heh Jul 09 20:13:35 well, its bad and good. if that many companies are using OE, that says something about the project. not everyone is a team player :) Jul 09 20:13:44 Jay7: we can't force them. And doing so would often make it even more problematic to work with them Jul 09 20:14:00 I just think from moral aspects Jul 09 20:14:10 we should ask them for participate at least Jul 09 20:14:11 oh, the boss is coming Jul 09 20:14:12 OE's MIT for a reason :) Jul 09 20:14:15 * stefan_schmidt hides :) Jul 09 20:14:22 hah Jul 09 20:14:24 busted Jul 09 20:14:31 * kgilmer hides in the corner Jul 09 20:14:32 jconnolly: so early Jul 09 20:14:42 kergoth_: agreed, its always a problem to get companies playing together Jul 09 20:14:48 forcing them is not really an option Jul 09 20:14:57 yes encouraging is Jul 09 20:14:57 take the kernel Jul 09 20:15:13 OE needs some marketing and PR people :) Jul 09 20:15:21 well, you can *try* to force them via license constraints, but for us encouraging adoption has always been more important than ensuring everyone contributes Jul 09 20:15:23 GPL forces somehow, but before they learned about the benefits they still were running forks Jul 09 20:15:29 few folks I was talking to has an opinion that its no gain to support something upstream Jul 09 20:15:32 its an ongoing process Jul 09 20:15:42 khem, now that's just idiotic. Jul 09 20:15:51 yes I was amazed Jul 09 20:16:03 one of OE's biggest strong points is the collaborative pile of metadata where everyone benefits from everyone elses work, even in other distros and machines Jul 09 20:16:07 but they think it will not help in their TTM Jul 09 20:16:08 to not see that is.. amazing Jul 09 20:16:12 hrmph Jul 09 20:16:17 and I asked him why did they use open source Jul 09 20:16:27 and then he says to hit the market first :) Jul 09 20:16:29 wait till they have to maintain a bunch of features long term as local branches when they could just pushi t and forget about it Jul 09 20:16:39 more work to stay on your own Jul 09 20:16:46 * kergoth_ shakes head Jul 09 20:16:52 then I asked what does he think about doing it yourself. becasue someone contributed thats what you are using now Jul 09 20:16:55 kergoth_: normally they would just freeze the meta data and go along Jul 09 20:17:05 kergoth_: no updates in consumer electronics :) Jul 09 20:17:06 well, if they don't want improvements, sure Jul 09 20:17:09 and they he said we only see quarter at a time Jul 09 20:17:11 * kergoth_ rolls eyes Jul 09 20:17:20 khem, ugh Jul 09 20:17:22 * jconnolly shudders in fear of updates Jul 09 20:17:25 that's really shortsighted Jul 09 20:17:44 kergoth: surprisingly most of execs think that way Jul 09 20:17:46 I have met Jul 09 20:17:49 about no updates in consumer electronics that is true :( Jul 09 20:17:56 updates are coming as new device.. Jul 09 20:18:04 heh Jay7 thats right Jul 09 20:18:25 thats more money in bottomline Jul 09 20:18:46 I think we can only work with the resources and companies we have and go forward with it. Hopefully other find out that it makes sense mid and long term and join Jul 09 20:18:51 with the proliferation of internet connected devices, it wouldn't surprise me to see more capable of automatic firmware updates, but whether they're willing to or not.. Jul 09 20:19:20 stefan_schmidt, and it's still good for us when all those companies leverage our stuff, at least if someone finds out about it :) Jul 09 20:19:24 we should say on every event about returning changes and participating in project Jul 09 20:19:42 on every event for every company Jul 09 20:20:01 they should understand what will they get from collaboration Jul 09 20:20:16 kergoth_: agreed. I don't have bad bloor regarding companies not giving back. Its their choice. They just miss so much knowledge and the chance to improve things for them. Jul 09 20:20:19 "Hello everyone, welcome to open source for dummies..." Jul 09 20:20:24 and better when this will measured in money :) Jul 09 20:20:49 open source for big bosses :) Jul 09 20:21:06 stefan_schmidt, agreed. it'll bite them eventually, but sadly most probably won't even realize what they've missed out on Jul 09 20:21:10 and for marketoids :) Jul 09 20:21:30 so, lets come back what we _can_ do right now Jul 09 20:22:03 better commit quality, better repo quality, tiome based releases, better buid coverage Jul 09 20:22:04 build Jul 09 20:22:26 * kergoth_ thinks we need to sit down at some point and figure out how to make it easier to branch/sync with OE, for OE-based products Jul 09 20:22:34 it's way, way too much work to sync back up Jul 09 20:22:55 kergoth_: fully agreed! Jul 09 20:23:07 your bonuses are not tied to 5 year plans Jul 09 20:23:13 they are tied to yearly plans Jul 09 20:23:18 kergoth_: Its gettign a real pain to get all needed stuff for buglabs into stable. its doable but a pain Jul 09 20:23:18 and so are your bosses Jul 09 20:23:31 hence no one gives damn about future Jul 09 20:23:35 just think about the newly added openjdk-6 stuff that need llvm Jul 09 20:23:38 stefan_schmidt, was a royal pain at MV too. not quite as bad at mentor, but still more trouble than it should be Jul 09 20:23:43 they just see enough that will fetch them the bucks Jul 09 20:24:19 kergoth: syncing is a worthy goal Jul 09 20:24:27 kergoth: but we change api's Jul 09 20:24:36 like crazy Jul 09 20:24:41 versioning classes somehow would help Jul 09 20:24:47 but there's still a need for better tools Jul 09 20:24:49 we should formalize bb syntax Jul 09 20:25:22 for 3 different cases: branch of the OE repo, own collection on top of OE repo, more minimal repo based on OE metadata copied over Jul 09 20:26:20 speaking of which, pulling in collections from multiple sources can be problematic.. recipes in one makes assumptions about classes that its collections had.. almost need things to prefer the classes in their own collections, or something Jul 09 20:27:35 https://dl.dropbox.com/u/112715/Documents/Sync%20from%20OE%20-%20Public.html/index.html - that makes me sad Jul 09 20:27:41 khem: amen Jul 09 20:27:43 :-) Jul 09 20:28:09 It looks like people started to get worried about stable/2009 migration path :-) Finally :-D Jul 09 20:28:49 otavio: always a question of needs :) Jul 09 20:29:01 kergoth_: we here used a branched tree Jul 09 20:29:11 ideally, you'd be able to pick and choose collections of oe metadata from mv, mentor, poky, etc, and include them in a build, and have things not explode horribly Jul 09 20:29:23 stefan_schmidt: yes; if you look at ML archive I brought this question up two times already Jul 09 20:29:28 kergoth_: worthy goal Jul 09 20:29:30 otavio, mv was slightly more trouble just because it used a more minimal repo, to reduce parse time Jul 09 20:29:30 isn't that montavista's entire business model? making oe "stable" ? Jul 09 20:29:47 kergoth_: like poky did? Jul 09 20:29:54 stefan_schmidt, yep Jul 09 20:29:59 syncing that is a fucking nightmare Jul 09 20:30:10 hrm, maybe "was", i see a giant android logo at montavista.com Jul 09 20:30:36 gosh Jul 09 20:30:38 unless they've completely changed their design since i left a couple months ago, no, not was Jul 09 20:30:42 heh Jul 09 20:31:05 but its not entirely about stability, folks like mv and mentor add value Jul 09 20:31:21 * kergoth_ shrugs Jul 09 20:31:32 stable in upstream is absolutely necessary Jul 09 20:31:50 kergoth_: by proposal was, and continue to be, that we (OE) does a merge of stable into dev once a mounth Jul 09 20:32:08 otavio, khem: I will finish my new stable branch RFC and send it out. Also add the idea of maybe having an ongoing flow of changes into it via testing Jul 09 20:32:13 * kergoth_ stabs xchat Jul 09 20:32:18 kergoth_: by proposal was, and continue to be, that we (OE) does a merge of stable into dev once a mounth Jul 09 20:32:40 that sounds very good Jul 09 20:32:46 dev should alwyas have everything stable does, and then some Jul 09 20:33:00 hi, does someone knoes bitbake? Jul 09 20:33:01 anyone tried building apr or apr-util directly recently? Jul 09 20:33:12 I've: Jul 09 20:33:18 otavio: the changes should go into .dev first may be Jul 09 20:33:19 Think of the other benefit kergoth -- if stable tracks dev monthly, perhaps I'll even move to stable. Jul 09 20:33:26 hehe Jul 09 20:33:27 Unknown fetch Error: [Errno 2] No such file or directory: sources/git_gitorious.org.htc-msm-2-6-32.leviathan-incoming.git_636fa4daf243826ef6cebb64dd0509f3b079fcb5.tar.gz Jul 09 20:33:28 kergoth_: yes; but try to merge stable into dev today ... Jul 09 20:33:31 what should I rm? Jul 09 20:33:34 khem: somewhat Jul 09 20:33:36 otavio, i think we need to start over :) Jul 09 20:33:47 hansdampf: I think we ought to have an stable and a testing Jul 09 20:33:50 grr Jul 09 20:33:51 GNUtoo|laptop: the .md5sum file Jul 09 20:33:54 khem, if we regularly merged stable into dev, it wouldn't matter where it originated Jul 09 20:33:59 khem, that's already removed Jul 09 20:34:00 it'd end up in .dev either way Jul 09 20:34:03 khem: think we ought to have an stable and a testing Jul 09 20:34:08 otavio: because we have been waiting to long to get newer stuff into stable Jul 09 20:34:11 kergoth: yeah merge early merge often is mantra Jul 09 20:34:21 khem, there is only the .lock file Jul 09 20:34:25 khem: so bugfixes go into testing and from it to dev and stable Jul 09 20:34:31 Aside: thoughts on a bbclass SONAME / major version marker? Jul 09 20:34:36 khem: new things to dev Jul 09 20:34:45 otavio, khem: I want all this ideas as answer to my proposal :) Jul 09 20:35:03 * kergoth_ ponders Jul 09 20:35:24 kergoth: thats fine realy implementing GNU versioning like stuff for bb classes would be great Jul 09 20:35:31 In theory, bugfixes ought to go to stable and then merged into dev Jul 09 20:35:41 and avoid using cherry-pick Jul 09 20:35:45 I think we'd really need a new addition to the syntax for the versioning Jul 09 20:35:53 this is not always possible but is the ideal Jul 09 20:36:09 this way we can inspect the ast in bitbake to determine the versions available Jul 09 20:36:14 doing that we avoid duplicated changesets in history Jul 09 20:36:21 otavio: I would ask .devs to submit 2 patches one for stable and one for .dev Jul 09 20:36:24 things should go to .dev first no? Jul 09 20:36:33 that's why I suggested testing Jul 09 20:36:47 testing could be merged into dev daily Jul 09 20:36:55 and into stable once it proves stable Jul 09 20:37:00 ah Jul 09 20:37:13 how much manpower and testing does this assume? Jul 09 20:37:17 course, that assumes we have a way to prove something as stable ;) Jul 09 20:37:24 exactly Jul 09 20:37:26 I've not the time to use .stable or .testing Jul 09 20:37:29 Crofton|work: lot Jul 09 20:37:31 I do only oe.dev Jul 09 20:37:37 kergoth_: well; we have a stable branch that needs this prove too Jul 09 20:37:42 we have enormous distro Jul 09 20:37:42 otavio, indeed Jul 09 20:37:45 right now stable is stable because it is "hard"o get stuff in :) Jul 09 20:37:55 kergoth_: so not much diference there Jul 09 20:38:08 Crofton|work: this shouldn't change Jul 09 20:38:24 yeah, it does seem to work somewhat Jul 09 20:38:25 Crofton|work: the only change I think we need is a way to have it all into dev right Jul 09 20:38:33 for people that need something that does not change a lot Jul 09 20:38:37 yeah Jul 09 20:38:43 Crofton|work: chrry-pick is a horrible way of doing it Jul 09 20:38:49 otavio: we need a proof of testing before its committed to stable and having it on .dev would be it Jul 09 20:38:55 one way Jul 09 20:38:56 but, in any stable branch, there will always be divergence Jul 09 20:38:57 Crofton|work: but putting directly into stable is wrong and risky Jul 09 20:39:09 otavio, git NEEEEDS a way to keep track of cherry picks :( Jul 09 20:39:18 if the thing has to be changed at all, the patchid changes Jul 09 20:39:24 can no longer identify where it came from Jul 09 20:39:36 khem: my idea was: if it is new and not intended to be in stable, go in dev Jul 09 20:40:02 khem: if will be asked to be put into stable, put in testing Jul 09 20:40:11 khem: so we merge testing into stable Jul 09 20:40:50 khem, sorry to interupt but do you have another idea for my issue, I spent a lot of yesterday night trying to fix that without success Jul 09 20:40:51 otavio: Crofton|work cherry picks are merge friendly though Jul 09 20:40:57 kergoth_: yes but it doesn't has it and this is natural from the way it works Jul 09 20:41:08 khem: in theory yes Jul 09 20:41:10 well Jul 09 20:41:11 i should say Jul 09 20:41:16 we need a new porcelain Jul 09 20:41:17 khem: but only if we do it ofthen Jul 09 20:41:29 GNUtoo|laptop: remove sources/git_gitorious.org.htc-msm-2-6-32.leviathan-incoming.git_636fa4daf243826ef6cebb64dd0509f3b079fcb5.tar.gz.* Jul 09 20:41:46 i started playing with something for it - http://github.com/kergoth/git-origin Jul 09 20:41:52 but it proved to be a huge pain in the ass Jul 09 20:42:00 kergoth: I plan to be more active on next stable Jul 09 20:42:04 ok, I'll try again,thanks Jul 09 20:42:10 kergoth_: humm please lets to not complicte it too much :P Jul 09 20:42:24 otavio, :) Jul 09 20:42:37 Crofton|work: but lookign forward to get the new llvm, the ARM gcc patches and openjdlk into stable is at best hard :) Jul 09 20:42:41 it really gets messy if you consider cherry picks where multiple commits become one, or one becomes multiple Jul 09 20:42:45 then your head decides to explode Jul 09 20:43:01 ah nice it fetched now,I don't know why,previous build sources/git_gitorious.org.htc-msm-2-6-32.leviathan-incoming.git_636fa4daf243826ef6cebb64dd0509f3b079fcb5.tar.gz.* was removed too Jul 09 20:43:09 stefan_schmidt: you need gcc 4.4+ for all jdk and llvm stuff Jul 09 20:43:13 kergoth_: so use a branch for it, as I suggested Jul 09 20:43:15 to work it better Jul 09 20:43:22 thanks a lot Jul 09 20:43:37 GNUtoo|laptop: how old is your bitbake Jul 09 20:43:44 GNUtoo|laptop: I have fixed it on bb master Jul 09 20:43:47 master Jul 09 20:43:48 khem: hu, its all fine with 4.3 here :) Jul 09 20:43:54 stefan_schmidt, maybe it is time for stable.2010 :) Jul 09 20:44:04 stefan_schmidt: yes with backports sure Jul 09 20:44:07 Already up-to-date. Jul 09 20:44:11 Crofton: I just send the mail as RFC to the list :) Jul 09 20:44:12 changes of that magnitude break the stable concept ... Jul 09 20:44:19 stefan_schmidt, good :) Jul 09 20:44:25 stefan_schmidt: but as we have more and more devices on armv7 newer gcc is needed Jul 09 20:44:26 khem: sure, forward I would like a newer gcc Jul 09 20:44:38 otavio: dealing with long lived branches and cherry picks is a really common problem, would be nice to have multiple tools available to solve it. Jul 09 20:44:39 heh Jul 09 20:44:40 something like 4.5 or even 4.6 Jul 09 20:44:47 khem, btw git fetcher can't fetch from gitorious, I tried yesterday to fix that but I'll just tell people to pull manually for gitorious stuff Jul 09 20:45:00 khem: agreed with an ongoing but slowed down (for testing and qa) flow of patches that would be easier imho Jul 09 20:45:04 instead because I't too complicated/time consuming for me Jul 09 20:45:07 GNUtoo|laptop: ok I dont know about that Jul 09 20:45:11 ok Jul 09 20:45:13 Aside: if versioning for classes requires a new addition to the syntax, should it be postponed until a bb2 syntax is created, to avoid compatibility issues? I'm thinking yes Jul 09 20:45:37 stefan_schmidt: we need to automate testing to reduce errors Jul 09 20:45:47 khem: agreed Jul 09 20:45:50 automated testing would be a dream Jul 09 20:46:01 kergoth_: landing autorized ;-) Jul 09 20:46:01 stefan_schmidt: something like automatic build of an image and then run the image with qemu Jul 09 20:46:20 khem: So you want a buildbot setup that buidls the different qemu steups and reports where? mail? Jul 09 20:47:03 stefan_schmidt: actually grep the offending commits with git bisect and send agents to offenders home right away :) Jul 09 20:47:09 khem: what should we do when a commit breaks the build auto revert? Jul 09 20:47:22 so auto revert and sending out a blame :) Jul 09 20:48:00 stefan_schmidt: both Jul 09 20:48:49 hi jconnolly Jul 09 20:48:58 hi GNUtoo|laptop Jul 09 20:49:16 khem: It must be crystal clear then that reverts are not evil but normal in such a process. Nobody gets everything right. Jul 09 20:49:22 I heard that java was merged,nice and thanks a lot Jul 09 20:49:33 We need to make reverts socially acceptable then to kep people motivated Jul 09 20:49:47 stefan_schmidt: yeah but I fear that history will have so many reverts Jul 09 20:49:52 GNUtoo|laptop: thank woglinde and thebohemian, they did the heavy lifting ;D Jul 09 20:50:17 ok thanks but they're not here right now Jul 09 20:50:18 i'm still building from the jalimo overlay Jul 09 20:50:25 ah stable.... Jul 09 20:50:30 indeed Jul 09 20:50:36 * GNUtoo|laptop loves .dev Jul 09 20:50:39 i am building against oe-dev too Jul 09 20:50:41 khem: hmm, good point Jul 09 20:50:44 ah nice Jul 09 20:50:44 03Klaus Kurzmann  07org.openembedded.dev * r86119e5c44 10openembedded.git/recipes/freesmartphone/cornucopia.inc: Jul 09 20:50:44 cornucopia.inc: bump FSO_CORNUCOPIA_SRCREV Jul 09 20:50:44 Signed-off-by: Klaus Kurzmann Jul 09 20:52:41 khem, in case you or someone is intereted in fixing bitbake here's the error: http://pastebin.com/6VraNBEH Jul 09 20:52:49 it works fine manyally Jul 09 20:53:17 GNUtoo|laptop: right now I am interested to fix my stomach :) Jul 09 20:53:21 ok Jul 09 20:53:22 * khem ponders for food Jul 09 20:53:27 it was for future use Jul 09 21:07:03 night all Jul 09 21:13:37 hi all Jul 09 21:22:29 how to remove the udev completly from angstrom distribution ... i have changed the conf file with angstrom-2008.1.conf:PREFERRED_PROVIDER_hotplug = "mdev" but still it is building with udev is there any other place which i am missing Jul 09 21:24:43 newbie_sreddy: bitbake -g Jul 09 21:24:53 that should dump the dep chain graph Jul 09 21:25:06 look in the graph and see whats pulling udeb Jul 09 21:25:07 i ll try that khem Jul 09 21:25:08 udev Jul 09 21:32:11 ""console-image" -> "udev" [style=dashed]" i think console-image is pulling that Jul 09 21:49:29 Khem : after replacing "udev" with "mdev " in the PREFERRED_PROVIDER_hotplug = "mdev" are there any changes which i should do .. to remove udev completly building into my image ? Jul 09 22:03:03 newbie_sreddy: you might want to remove udev from deps Jul 09 22:03:41 i am sorry if i am asking silly Qs but can please let me know wher i can find deps Jul 09 22:04:00 u mean the DEPENDS in .bb files Jul 09 22:04:10 ? Jul 09 22:15:23 newbie_sreddy: those .dot files will let u know where to remove it from Jul 09 22:15:40 03Khem Raj  07org.openembedded.dev * r5e067562e2 10openembedded.git/recipes/gcc/ (gcc-4.4.4.inc gcc-4.4.4/gcc-arm-cp15-tpreg-for-TLS.patch): Jul 09 22:15:40 gcc-4.4.4: Use CP15 register for TLS access on armv7-a. Jul 09 22:15:40 * ARMv7 was using -mtp=soft where as the CP15 register for TLS Jul 09 22:15:40 is available and should be used. This should improve the performance Jul 09 22:15:40 of TLS access. Jul 09 22:19:48 are you sure you really want to do that? Jul 09 22:20:00 that's an abi break and the performance gain is not going to be very large. Jul 09 22:21:30 meh Jul 09 22:22:33 kergoth: quite so Jul 09 22:40:44 pb__: hmmm Jul 09 22:41:08 pb__: I think yes I should revert it Jul 09 22:42:38 hi Jul 09 22:42:53 pb__: I dont know if it is an abi break though because kernels automatically configure for cp15 tp Jul 09 22:43:10 pb__: unless we have fixed kernels not to do it Jul 09 22:43:16 which I dont think we have Jul 09 22:45:05 i have replace the udev with mdev in the distro conf files ... when i did bitbake -g console-image it gave dependecy list but it looks like many other packages are depending on udev ..... i am using udev version 151 for kernel 2.6.22 and facing problem with udev ... is it a good idea to use older verion of udev (eg udev.121 ) or to use mdev Jul 09 22:47:23 03Khem Raj  07org.openembedded.dev * r15482e9360 10openembedded.git/recipes/gcc/gcc-4.4.4.inc: Jul 09 22:47:24 gcc-4.4.4.inc: Dont apply gcc-arm-cp15-tpreg-for-TLS.patch as it might be breaking ABI for armv7 Jul 09 22:47:24 Signed-off-by: Khem Raj Jul 09 22:47:26 pb__: I revert it Jul 09 22:47:41 03Klaus Kurzmann  07org.openembedded.dev * r00f6f19f53 10openembedded.git/recipes/freesmartphone/fsogsmd/0001-fsogsmd-update-sysfs-node-in-config-for-openmoko_gta.patch: Jul 09 22:47:41 fsogsmd_git.bb: update patch to fix config for newer kernels on GTA02 Jul 09 22:47:41 Signed-off-by: Klaus Kurzmann Jul 09 22:50:55 hmm all kernels seems to have CONFIG_HAS_TLS_REG=y so it wont be a problem Jul 09 22:51:22 but I think one has to rebuild right Jul 09 22:52:16 but with current kernel configs it should be broken with gcc 4.4 anyway Jul 09 22:52:23 for armv7 Jul 09 22:52:31 armv7 ? Jul 09 22:52:45 dcordes_: TLS access Jul 09 22:53:07 I built quite some oe stuff with 4.4.4 and used it on armv7 running 2.6.32 Jul 09 22:53:23 dcordes_: multithreaded ? Jul 09 22:53:44 using thread variables Jul 09 22:54:02 CONFIG_HAS_TLS_REG=y Jul 09 22:54:28 dcordes_: that would mean kernel is returning TLS in a CP15 register Jul 09 22:54:52 whereas userspace is expecting it in special kernel vaddr 0xffff0ff0 Jul 09 22:55:04 I dont know how it worked Jul 09 22:57:05 dcordes_: check arch/arm/kernel/traps.c Jul 09 22:57:09 khem: I don't understand what you are saying but it works. Jul 09 22:57:20 1sec Jul 09 22:57:31 dcordes_: look for CONFIG_HAS_TLS_REG Jul 09 22:59:33 khem: the line was pasted from .config I use Jul 09 22:59:39 it is enabled in my kernel Jul 09 23:00:39 dcordes_: and SMP ? Jul 09 23:03:37 khem: htcleo only got one cpu Jul 09 23:04:00 well two but the other one is dedicated for the baseband chip Jul 09 23:04:06 yeah ok I leave it as it is Jul 09 23:04:09 s/chip/system/ Jul 09 23:05:35 kergoth: what do you think about the quilt patch Jul 09 23:06:25 dcordes_: can you try with gcc 4.5 ? Jul 09 23:06:49 dcordes_: i.e you have to rebuild everything Jul 09 23:07:18 khem: ok. I am building on a new computer though and I'm encountering some host specific problems Jul 09 23:07:25 * Jay7 -> sleep Jul 09 23:07:32 khem: if you can help me a bit fixing those I can give you test results soon Jul 09 23:09:44 dcordes_: what distro do you have on it Jul 09 23:09:54 I think it is ubuntu karmic Jul 09 23:10:06 ok Jul 09 23:10:12 but it's not distro specific cause I din't see that error with same distro on different pc Jul 09 23:10:37 well depends what all you have installed Jul 09 23:10:46 so whats the error Jul 09 23:11:07 I will do a fresh rebuild and put the tinderbox link 1 sec Jul 09 23:14:41 khem: http://privatepaste.com/192e5c0bb1 Jul 09 23:15:32 /usr/local/lib/libz.so.1 Jul 09 23:15:36 where does this come from Jul 09 23:18:25 dcordes_: did you try to clean build this one recipe Jul 09 23:18:34 khem: I don't know.. it has been there since root ran an upgrade Jul 09 23:19:05 oh I didn't clean sorry. well it's same error running from clean. but let me check Jul 09 23:19:33 khem: same libz warning also appears starting git Jul 09 23:19:53 dcordes_: updates should not install stuff into /usr/local I think Jul 09 23:20:15 so do this dpkg-query -S /usr/local/lib/libz.so.1 Jul 09 23:20:39 $ dpkg-query -S /usr/local/lib/libz.so.1 Jul 09 23:20:40 it should show you which package it belongs to Jul 09 23:20:41 03Klaus Kurzmann  07org.openembedded.dev * reefd00949a 10openembedded.git/recipes/freesmartphone/fsogsmd_git.bb: Jul 09 23:20:41 fsogsmd_git.bb: fix striplevel for modified config patch Jul 09 23:20:41 Signed-off-by: Klaus Kurzmann Jul 09 23:20:41 dpkg: /usr/local/lib/libz.so.1 not found. Jul 09 23:21:01 dcordes_: this means that its installed manually Jul 09 23:21:17 dcordes_: is it shared box Jul 09 23:21:22 apt-get install --reinstall libz maybe Jul 09 23:21:30 yes I don't have root Jul 09 23:21:45 thats is not going to remove it from /usr/local Jul 09 23:22:18 dcordes_: or sudo Jul 09 23:22:29 if you have sudo access then you can move it away as well Jul 09 23:22:46 I don't unfortunately Jul 09 23:23:07 do you think it's related to perl-native permission problem? Jul 09 23:24:47 /home/oedevel/C thats a strange dir Jul 09 23:25:38 true Jul 09 23:28:10 dcordes_: opendir(./../../../../../../../../..) Jul 09 23:28:16 thats strange too Jul 09 23:28:19 yes that is strinking Jul 09 23:28:28 striking Jul 09 23:28:32 dcordes_: there is no symlinks Jul 09 23:28:38 involved Jul 09 23:28:42 aha Jul 09 23:28:54 so what could be missing in the host configuration ? Jul 09 23:32:59 dcordes_: did you rebuild this recipe Jul 09 23:33:34 yep hold on Jul 09 23:34:14 http://tinderbox.openembedded.net/public/logs/task/6481830.txt Jul 09 23:38:06 khem: same problem Jul 09 23:38:21 I will try around with symlinks manually Jul 09 23:44:34 khem: hm I can follow symlinks normally Jul 09 23:46:25 khem: ok libz mystery solved. this and other libs were installed by some directadmin program Jul 09 23:56:30 dcordes_: I dont know atm what could be wronf Jul 10 00:01:10 dcordes_: it seems to be a file permissions problem Jul 10 00:08:59 khem: ok Jul 10 00:09:08 khem: since the problem was first seen I removed tmp Jul 10 00:09:29 khem: so it's something persistent Jul 10 00:11:21 dcordes_: so nothing in user/groups changed ? Jul 10 00:11:24 for this user Jul 10 00:12:51 whats is your umask Jul 10 00:13:14 dcordes_: mine is 0022 Jul 10 00:14:57 dcordes_: problem could be that the usr/grp of the username that you are using does not have read permissions on subdirectories Jul 10 00:15:30 dcordes_: write a small perl program which has abs_path(".") Jul 10 00:15:49 and try to execute it in the same dir where perl-native is failing Jul 10 00:16:19 khem: how can I check what umask I got ? Jul 10 00:16:40 OTE: Running task 15 of 15 (ID: 4, /home/oedevel/openembedded/recipes/perl/perl-native_5.10.1.bb, do_build) Jul 10 00:16:43 NOTE: Tasks Summary: Attempted 15 tasks of which 0 didn't need to be rerun and 0 failed. Jul 10 00:16:50 bitbake -b recipes/perl/perl-native_5.10.1.bb Jul 10 00:17:04 older version is picked by default Jul 10 00:19:05 let's see if the compile log has same ultra weird path names. Jul 10 00:21:45 khem: perl-native-5.10.1-r4 http://linuxtogo.org/~lgorris/super-weird-oe-paths.txt Jul 10 00:22:10 it contains many ../../../ Jul 10 00:22:34 but not ultra long ./../../../../../../../../.. like the failing older version recipe Jul 10 00:23:30 khem: is it ok to use angstrom for the gcc 4.4.5 armv7 CONFIG_HAS_TLS_REG=y ? Jul 10 00:23:43 khem: or do you need it tested with minimal distro ? Jul 10 00:28:46 khem: local.conf http://privatepaste.com/89b29787e0 Jul 10 01:51:05 khem: ok I'm running with posted local.conf . the minimal-image is almost done already. maybe you can start thread on ml or a bug regarding it so I can share the test results **** ENDING LOGGING AT Sat Jul 10 02:59:56 2010