**** BEGIN LOGGING AT Wed Sep 08 02:59:59 2010 Sep 08 05:25:24 ka6sox, didn't have time yet to see our sysop, see if he could do the traceroute, but ping does work, from here to melo is ttl 53, time 162 ms Sep 08 05:29:39 thats not bad Sep 08 05:31:35 nope, sysop is not in yet, but will try to see if he can do a traceroute (actually not sure why traceroute would not work while ping does Sep 08 05:49:25 03Khem Raj  07org.openembedded.dev * rd17f35cc41 10openembedded.git/recipes/eglibc/eglibc_svn.bb: Sep 08 05:49:25 eglibc_svn.bb: Bump SRCREV Sep 08 05:49:25 Signed-off-by: Khem Raj Sep 08 06:12:01 Hi all Sep 08 06:12:18 I just want to know which recipe builds the filesystem Sep 08 06:12:42 gm Sep 08 06:12:53 builds the filesystem? Guess you mean, build the image Sep 08 06:13:08 the filesystems themselves are part of the linux kernel Sep 08 06:13:21 images reside in recipes/images (e.g. recipes/images/console-image) Sep 08 06:14:25 thanks eFfeM_work Sep 08 06:15:38 this recipe deals with root file system which hold all the extra packages we want to be on the target along kernel? Sep 08 06:15:49 yes Sep 08 06:16:09 OK. cool Sep 08 07:31:44 morning Sep 08 07:32:17 morning Sep 08 07:36:27 good morning Sep 08 07:52:35 03Koen Kooi  07org.openembedded.dev * ree49efcd2b 10openembedded.git/recipes/linux/ (files/configs/.empty multi-kernel.inc): multi-kernel: more do_unpack unbreaking Sep 08 08:49:03 hm, i have an unpacking issue on linux-libc-headers for nios2, it seems it wants to unpack a file that is not in SRC_URI Sep 08 08:49:05 see http://www.pastie.org/1145360 Sep 08 08:49:28 anyone an idea (ericben, i assume this is not related to the unpack changes you made) Sep 08 08:55:44 ericben|away: ^^ Sep 08 08:56:56 03Graeme Gregory  07org.openembedded.dev * rd1e7b0b7a5 10openembedded.git/MAINTAINERS: Sep 08 08:56:56 MAINTAINERS : correct my entry Sep 08 08:56:56 Having very little time to develop with OE at moment so not really maintaining Sep 08 08:56:56 anything not Angstrom related. Sep 08 09:24:16 * XorA is left wondering why linux does not support PATA cdroms anymore Sep 08 09:25:13 what's PATA? Sep 08 09:25:16 :) Sep 08 09:26:18 PAT is three generations before SATA: PATA -> QATA -> RATA -> SATA ;-) Sep 08 09:26:26 and whatever happened to the wiki transfer, I thought that had been done Sep 08 09:26:27 PATA Sep 08 09:27:14 eFfeM_work: I know, it was attempt for joke :) Sep 08 09:27:38 "-) Sep 08 09:27:41 :-) Sep 08 09:27:44 two distros, Fedora and Ubuntu both totally broken with regards to cd-roms Sep 08 09:29:11 thank friday for microsoft is all I can say Sep 08 09:31:44 well oe var stuff seems broken too, if I say RDEPENDS += "x" followed by RDEPENDS_mymachine += "y" the value of x seems overwritten Sep 08 09:31:50 or am I missing something here Sep 08 09:32:58 thats why we use the contruct TEMP = "" TEMP_mymachine="blah" RDEPEMD += "${TEMP}" Sep 08 09:35:11 ah ok, XorA, thanks! Sep 08 09:35:40 its complex issues with expansion order that probably only zecke/kergoth/RP understand Sep 08 09:36:41 I got something similar with SRC_URI = "x" and SRC_URI_mymachine = "y" where still I get x + y Sep 08 09:37:02 and i am fairly sure I only got y a few months ago Sep 08 09:37:06 see my pastie above Sep 08 09:49:23 good morning Sep 08 10:27:33 03Enrico Scholz  07org.openembedded.dev * r9e58422868 10openembedded.git/recipes/ncurses/ (ncurses-5.7/libtermcap.so ncurses_5.7.bb): Sep 08 10:27:33 ncurses: added libtermcap.so file for backward compatibility Sep 08 10:27:34 Signed-off-by: Enrico Scholz Sep 08 10:33:38 how does this work: bb.data.getVar('P', d, True) , P is the variable name, what is "d"? and what's the bool value for? Sep 08 10:37:16 'd' is the datastore, and the bool is whether you want expansion or not Sep 08 10:40:45 where does the datastore come from? or is "d" defined by bitbake? Sep 08 10:41:28 searching through bbclasses, trying to figure that out Sep 08 10:41:40 what's the context? Sep 08 10:41:49 if this is in a task, it is passed to you by bitbake Sep 08 10:42:00 I am writing an own bbclass and yes, creating own tasks Sep 08 10:42:12 and I want to get the "S" variable value for the source path Sep 08 10:44:59 bb.data.getVar('S', d, True) Sep 08 10:45:03 that should be all there is to it Sep 08 10:45:45 oh, ok.. Sep 08 10:45:50 was just unsure where that d is coming from :) Sep 08 10:45:52 thanks Sep 08 10:46:07 hi all Sep 08 10:46:12 i have one question Sep 08 10:48:11 i am merging native and non-native recipes, if the non-native recipe has its native package in its depends, how should i handle that Sep 08 10:48:46 it give error that *Dependancy loops are found* Sep 08 11:03:18 hey guys, i've been playing with using my local git tree inside an OE build, i tried SRC_URI = "git:///home/richard/kernels/linux-2.6-custom/;protocol=file;branch=tester" but the fetcher fails to fetch that. Does anyone have a working example of this? Sep 08 11:06:01 the log shows "From file *branch tester -> FETCH_HEAD", NOTE: Creating tarball of git repository , then fatal: Not a valid object name 1 Sep 08 11:37:45 fahad: remove the native dep, as far as I know it is automatically added. (anyway I never ran in to an issue without it) Sep 08 11:38:06 for extra space other than the default, is there any option other than IMAGE_EXTRA_SPACE ? Sep 08 11:38:17 fahad, simple test: clean native recipe, clean target recipe, remove native dep from merged recipe then bitbake target recipe Sep 08 11:38:26 in my local.conf ? Sep 08 11:39:33 ericben: did you have an idea on the unpacking issue (http://www.pastie.org/1145360) I didn't have this issue a few months ago Sep 08 11:39:38 eFfeM_work: i added DEPENDS_virtclass-native = "" after the DEPENDS line, and now both recipes are building fine Sep 08 11:39:53 ok, that works too Sep 08 11:40:06 it is also a good idea to peek how other recipes do it Sep 08 11:40:20 * eFfeM_work still thinks it would be useful to have DEPENDS_target Sep 08 11:41:28 eFfeM_work: ya, that would make life much simpler Sep 08 11:50:12 hi eFfeM_work, no idea for your issue but are you sure /home/hudson/jobs/FM_test/workspace/downloads/linux-2.6.34.tar.bz2 exists ? Sep 08 11:50:59 ericben it does not, but if you look at the first few lines of the pastebin, I expect it not to be used, I expect the SCR_URI_nios2 = "..." to override it Sep 08 11:51:11 and the file in that part is also expanded Sep 08 11:51:32 so it seems like an append or so instead of a redefine as I would expect Sep 08 11:52:01 is nios2 an override ? Sep 08 11:52:29 yes (at least I hope so :-) ) it is an arch Sep 08 11:52:41 and the file there gets expanded Sep 08 11:55:32 rebuilding now on my dev system, easier to instrument things over there Sep 08 12:03:44 eFfeM_work: no idea for your problem Sep 08 12:04:08 ok, i'll see if i can reproduce locally and diagnose it Sep 08 12:04:17 thanks for looking into it Sep 08 12:10:46 ich esse mal was, mahlzeit Sep 08 12:10:49 oops wrong window Sep 08 12:10:50 :) Sep 08 12:12:00 good appetite :-) Sep 08 12:12:40 thanks =) Sep 08 12:24:00 03Koen Kooi  07org.openembedded.dev * r260315cace 10openembedded.git/recipes/openjdk/openjdk-6-common.inc: openjdk: fix random behaviour due to _PN being a local override Sep 08 12:37:35 03Filip Zyzniewski  07org.openembedded.dev * rab5e49c586 10openembedded.git/conf/distro/jlime-2010.1.conf: Sep 08 12:37:36 jlime: switched from OABI to EABI. Sep 08 12:37:36 note: should we set TARGET_OS to linux-gnueabi even if distro Sep 08 12:37:36 supports machines other than ARM? Sep 08 12:37:36 03Filip Zyzniewski  07org.openembedded.dev * rd2cbace664 10openembedded.git/conf/distro/jlime-2010.1.conf: Sep 08 12:37:36 jlime: set virtual/libc preferred provider. Sep 08 12:37:37 base-image has virtual/libc in dependences and so needs it specified. Sep 08 12:37:37 03Filip Zyzniewski  07org.openembedded.dev * rd89f47cc3f 10openembedded.git/recipes/linux/ (2 files in 2 dirs): linux-jlime-jornada7xx: moved from 2.6.32 to 2.6.34. Sep 08 12:37:38 03Filip Zyzniewski  07org.openembedded.dev * r701fec42f4 10openembedded.git/conf/distro/jlime-2010.1.conf: Sep 08 12:37:39 jlime: removed some of PREFERRED_VERSION entries Sep 08 12:37:39 It seems that these hold back packages without a real reason. Sep 08 12:37:39 03Filip Zyzniewski  07org.openembedded.dev * r20f28f9117 10openembedded.git/conf/distro/jlime-2010.1.conf: Sep 08 12:37:40 jlime: using glibc-2.11 Sep 08 12:37:40 version 2.12 is pulled from svn now. no reason for that level Sep 08 12:37:41 of bleeding edge. Sep 08 12:37:54 03Filip Zyzniewski  07org.openembedded.dev * r254e5fc2ca 10openembedded.git/conf/distro/jlime-2010.1.conf: Sep 08 12:37:54 jlime: bumped up coreutils-native version. Sep 08 12:37:54 version 7.2 is not available in OE tree anymore. Sep 08 12:38:09 03Filip Zyzniewski  07org.openembedded.dev * rea3dc4fee9 10openembedded.git/conf/distro/jlime-2010.1.conf: Sep 08 12:38:09 jlime: fix glibc include Sep 08 12:38:09 Obsolete glibc include caused SyntaxErrors in uclibc bb files. Sep 08 12:38:09 03Filip Zyzniewski  07org.openembedded.dev * r046e7fe804 10openembedded.git/conf/distro/jlime-2010.1.conf: Sep 08 12:38:09 jlime: minor changes based on minimal.conf Sep 08 12:38:09 Our config file got a bit outdated. Sep 08 12:38:10 03Filip Zyzniewski  07org.openembedded.dev * r52405b05a8 10openembedded.git/recipes/dialog/dialog.inc: (log message trimmed) Sep 08 12:38:10 dialog: removed hardcoded -L/lib ld flag from configure. Sep 08 12:38:11 this flag has caused this behaviour on my system (from config.log): Sep 08 12:38:11 configure:9177: checking for initscr in -lncurses Sep 08 12:38:12 configure:9204: arm-oe-linux-gnueabi-gcc -march=armv4 -mtune=strongarm Sep 08 12:38:12 -mthumb-interwork -mno-thumb -o conftest -Os Sep 08 12:38:13 -isystem/home/builds/fresh/jornada7xx/tmp/sysroots/armv4-oe-linux-gnueabi/usr/include Sep 08 12:38:24 03Filip Zyzniewski  07org.openembedded.dev * rb487e344fc 10openembedded.git/conf/machine/jornada7xx.conf: Sep 08 12:38:24 jornada7xx: fix for bug #4951 Sep 08 12:38:24 Added bluez-dtl1-workaround to avoid: Sep 08 12:38:24 * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-base: Sep 08 12:38:25 * bluez-dtl1-workaround * Sep 08 12:38:25 * opkg_install_cmd: Cannot install package task-base. Sep 08 12:38:44 Oki, that was the first attempt to push from the development server. Sep 08 12:39:00 kergoth, pointers, or is it alright to do it like this? Sep 08 13:49:30 hi Sep 08 13:50:03 anyone know what the status of Qt4.6 is on OE? The recipes have their DEFAULT_PREFERENCE marked down Sep 08 13:50:21 morning Sep 08 13:51:18 mike_s: QT Embedded version 4.6.3 works fine. I haven't tested QT not embedded. Sep 08 13:52:49 ericben: qt embedded 4.6.3 targeting ARMv5 is failing in compile because the moc files have been built with the wrong version of the moc tool Sep 08 13:53:22 mike_s: strange it was building a few days ago but there were changes to the moc tools recently Sep 08 13:55:03 I also tried 4.6.0 from an earlier hash of OE that we had been sticking on. This had the same issue so it's possibly something to do with my system, but the moc inside the build directory was reporting its version as 4.5.2 Sep 08 13:55:26 If I do the same thing with the moc in the 4.6.3 build directory it has been built using the ARM compiler instead of the host one Sep 08 14:36:10 03Steffen Sledz  07org.openembedded.dev * ra8c64519f8 10openembedded.git/recipes/gtk+/ (gtk+_2.18.6.bb gtk+_2.20.0.bb gtk+_2.20.1.bb): Sep 08 14:36:10 gtk+: fix configure problem for native build Sep 08 14:36:10 Signed-off-by: Steffen Sledz Sep 08 14:36:10 Acked-by: Graeme Gregory Sep 08 16:05:49 ericben: Was your working version of Qt 4.6.3 cross-compiled? Sep 08 16:09:25 mike_s: yes for armv5 using angstrom 2008.1 Sep 08 16:11:56 ericben: we use a custom distro based very closely on angstrom 2008.1 and also armv5, tried on both i686 and x86_64 hosts Sep 08 16:12:19 ericben: the problem looks very much like moc, etc. are being built with the ARM compiler instead of the host one Sep 08 16:12:35 maybe the problem is in the "based very closely". Did you try using angstrom ? Sep 08 16:12:57 no but I will try that overnight Sep 08 16:14:01 mike_s: last successful build was using OE's gitrev : e2249025ea431966312885573c2c999913ac8679 Sep 08 16:23:10 03Roger Monk  07org.openembedded.dev * r76f0e713f4 10openembedded.git/recipes/mozilla/ (4 files in 2 dirs): Sep 08 16:23:10 mozilla: Add Category 'Network' to firefox/thunderbird for desktop files Sep 08 16:23:10 * Move desktop icons to appear alongside all other browser apps Sep 08 16:23:10 * Bump PR Sep 08 16:23:10 Signed-off-by: Roger Monk Sep 08 16:23:11 Signed-off-by: Koen Kooi Sep 08 16:23:11 03Roger Monk  07org.openembedded.dev * r60b39e1164 10openembedded.git/recipes/angstrom/ (2 files in 2 dirs): (log message trimmed) Sep 08 16:23:12 angstrom-uboot-scripts: tweak linuxtagdemo image boot script Sep 08 16:23:13 * Remove beagle detection (until fixed) Sep 08 16:23:13 * Pass camera variable on linux cmdline for LI vga camera Sep 08 16:23:14 * Remove usb fifo fix variable (not needed for later boards and helps reduce bootargs line length) Sep 08 16:23:14 * Bump PR Sep 08 16:23:15 Signed-off-by: Roger Monk Sep 08 16:23:33 03Roger Monk  07org.openembedded.dev * re23c8327aa 10openembedded.git/recipes/angstrom/angstrom-gdm-autologin-hack.bb: Sep 08 16:23:33 angstrom-gdm-autologin-hack : Fix missing quote mark + space Sep 08 16:23:33 * Missing " Sep 08 16:23:33 * Bump PR Sep 08 16:23:34 Signed-off-by: Koen Kooi Sep 08 16:23:34 03Stuart Gray  07org.openembedded.dev * r8400dfe735 10openembedded.git/recipes/taglib/taglib_1.6.3.bb: taglib: add 1.6.3 Sep 08 16:39:35 is there a way to get shadow files to be generated in the rfs images. I am looking at the shadow recipe and I can't figure out how the pwconv commands in the pkg_postinst will work unless the package manually installed Sep 08 17:14:31 ron: it should have dependency on the package which is providing pwconv if pwconv does not come from same package Sep 08 18:10:04 bitbake -e -b linux-libc-headers_2.6.34.bb spews errors Sep 08 18:10:19 ERROR: SRCREV was used yet no valid SCM was found in SRC_URI Sep 08 18:10:19 ERROR: Error evaluating '${@bb.fetch.get_srcrev(d)}' Sep 08 18:10:51 linux-libc-headers has become 1000 more complex than it was when I last saw is couple of months back Sep 08 18:13:13 yep, that's expected. bitbake -e of every recipe will do that Sep 08 18:13:25 it dumps all variables, in expanded form, including SRCREV, which is defined in bitbake.conf Sep 08 18:13:35 but expansion of it throws an error when no scm url is in SRC_URI Sep 08 18:14:19 kergoth_: doesnt that sound a problem Sep 08 18:14:40 it's not the only variable that throws an exception when expanded Sep 08 18:15:30 i'd like to see them all go away, but until the ref tracking code goes in, it'd be hard to implement a sanity check outside of the expansion Sep 08 18:15:34 kergoth_: is it something new ? Sep 08 18:15:41 since ideally it'd make sure we aren't referring to those variables Sep 08 18:15:42 no Sep 08 18:16:13 bitbake -e worked ok on stuff I tried some days ago Sep 08 18:16:25 oh, wait, i see, you're saying it actually errors out, rather than showing the info in comments in the output? Sep 08 18:16:32 yeah Sep 08 18:16:37 it's always thrown an exception, its just it was hidden and shown in comments Sep 08 18:16:56 does it only do that with -b? Sep 08 18:17:09 http://pastebin.com/cqBqxUhq Sep 08 18:17:38 lemme see Sep 08 18:18:04 looks like you have multiple errors going on Sep 08 18:18:10 File "/home/kraj/work/oe/bitbake/lib/bb/cooker.py", line 245, in showEnvironment Sep 08 18:18:10 logger.plain(env.getvalue()) Sep 08 18:18:11 AttributeError: Logger instance has no attribute 'plain' Sep 08 18:18:14 that's a new one, and shouldn't be happening Sep 08 18:18:18 yeah that seems to be new Sep 08 18:18:33 I have bb master Sep 08 18:19:03 will take a look after lunch. lib/bb/__init__.py sets up a custom logger class that provides things like plain, and installs it there Sep 08 18:19:14 somehow a logger is being created before that happens, which doesn't make much sense :\ Sep 08 18:19:32 we really, really need to get bitbake a good set of unit tests Sep 08 18:19:44 yeah same error without -b Sep 08 18:20:47 lib/bb/cooker.py is whats failin so may be instance is not passed to cooker Sep 08 18:21:11 logger instances are global Sep 08 18:21:17 they're shared Sep 08 18:21:19 hmm ok Sep 08 18:21:24 getLogger('foo') constructs the logger and caches it Sep 08 18:21:30 and subsequent getLogger calls fro foo return that instance Sep 08 18:21:53 this is why its a problem if a logger is somehow constructed before the new logging class is installed Sep 08 18:21:58 it'll cache that other class instance Sep 08 18:22:15 ok is plain attribute initialized in constuctor Sep 08 18:27:39 plain is a method of the class.. Sep 08 18:27:50 yeah just reading thru now Sep 08 18:27:51 line 48 of __init__.py Sep 08 18:27:55 lib/bb/msg.py Sep 08 18:28:06 wait, i see it Sep 08 18:28:27 try moving the logger stuff -- line 38 through 59 up to between the import of logging and the import of bb.msg Sep 08 18:28:32 so its set up before importing bb.msg Sep 08 18:28:34 i bet that's the problem Sep 08 18:28:42 see if that fixes it, please :) Sep 08 18:28:55 ok Sep 08 18:32:43 kergoth_: seems thats the problem here is the patch http://pastebin.com/UHhbzSRL Sep 08 18:32:49 it works now Sep 08 18:33:15 okay, thanks, will apply upstream Sep 08 18:33:24 I guess it deserves a comment too Sep 08 18:33:33 yeah, good point Sep 08 18:33:34 why the sequence here matters Sep 08 18:35:06 pushed, with a comment Sep 08 18:35:07 thanks Sep 08 18:35:13 cool Sep 08 18:40:55 verified it works Sep 08 18:41:00 khem, kergoth, thanks for looking at linux-libc-headers Sep 08 18:41:21 reason there is a specific nios2 tarball is because nios2 has an extra system call Sep 08 18:41:30 eFfeM: which bb version do you use Sep 08 18:41:34 oh Sep 08 18:41:40 1.10 (release version) Sep 08 18:41:43 you can extract that one patch and apply it Sep 08 18:41:50 it will be simpler Sep 08 18:42:06 works well with master Sep 08 18:42:13 I dont use 1.8 or 1.10 Sep 08 18:43:16 khem the patch for the logger (the one you gave above? ) not sure what that is related Sep 08 18:44:00 btw what version do you then use? bitbake git head? Sep 08 18:44:30 yes Sep 08 18:44:48 thats patch is for bb master Sep 08 18:45:36 that SRC_URI thing is just weird Sep 08 18:45:42 will that fix my SRC_URI issue? the patch does not seem to be too related (but ofc I do not know too much about the internals) Sep 08 18:45:48 no, its unrelated Sep 08 18:45:53 ah ok Sep 08 18:47:04 eFfeM: but if you switch to using bb master then it should fix your issue Sep 08 18:47:15 but then be prepared for some breakage sometimes Sep 08 18:47:34 I tried locating the function call but didn't really find bb.fetch.init to add debug statements to it Sep 08 18:48:02 khem, ah ok, actually it was my impression it still worked a week ago, guess I am mistaken Sep 08 18:48:37 will try bb master (probably locking to that version, I need to freeze the tools my project is using real soon now) Sep 08 18:56:20 khem btw, pulseaudio with ARM_INSTRUCTION_SET = "arm" did not work, get some other error about unknown instructions, haven't had time to loook into it yet Sep 08 19:12:40 is there an easy way to have all the dbg packages installed in an image when it is built? Sep 08 19:14:46 http://patchwork.openembedded.org/patch/2549/ Sep 08 19:14:53 Crofton: that may be of interest Sep 08 19:18:48 so I could use apply this patch and add Sep 08 19:18:58 IMAGE_FEATURES += "dbg" Sep 08 19:19:10 and get all the dbg packages installed in the image? Sep 08 19:21:08 yep Sep 08 19:21:10 that's the idea Sep 08 19:21:22 should work, but i think i'm the only one that's tested it :) Sep 08 19:21:46 I'll give it a whirl Sep 08 19:21:56 hopefully oprofile knows about the .debug stuff Sep 08 19:24:37 * Crofton hearts pw-am.sh Sep 08 19:24:50 hello... question about module_autoload and /etc/modutils/* ... let's say I want /etc/modutils/li3m02cm to deploy by default, and /etc/modutils/li3m02cm is composed of bmi_camera iommu2 omap3-iommu omap3-isp omap34xxcam Sep 08 19:24:58 I thought adding: Sep 08 19:25:23 module_autoload_li3m02cm = "bmi_camera \ ... etc Sep 08 19:25:46 to my recipe which requires linux.inc would suffice, but apparently not Sep 08 19:26:35 modutils is black magic to me though... Sep 08 19:27:49 03Eric Bénard  07org.openembedded.dev * rc3b768411c 10openembedded.git/recipes/rlpr/rlpr_2.05.bb: (log message trimmed) Sep 08 19:27:50 rlpr 2.05: unbreak recipe Sep 08 19:27:50 * source URL is no more working so use debian mirrors Sep 08 19:27:50 * fix GNU_HASH issue Sep 08 19:27:50 * tested on armv5 Sep 08 19:27:50 Signed-off-by: Eric Bénard Sep 08 19:27:50 Acked-by: Khem Raj Sep 08 19:28:09 03Eric Bénard  07org.openembedded.dev * r8f4400c820 10openembedded.git/recipes/rlpr/rlpr_2.05.bb: Sep 08 19:28:09 rlpr: upgrade to version 2.06 Sep 08 19:28:09 Signed-off-by: Eric Bénard Sep 08 19:28:09 Acked-by: Khem Raj Sep 08 19:28:09 Acked-by: Frans Meulenbroeks Sep 08 19:31:09 03Eric Bénard  07org.openembedded.dev * r41ee3c4d7c 10openembedded.git/recipes/mercurial/mercurial-native_1.6.3.bb: Sep 08 19:31:09 mercurial-native: add recipe Sep 08 19:31:09 * mercurial is a distributed SCM Sep 08 19:31:09 * having the native recipe inside OpenEmbedded gives the Sep 08 19:31:09 possibility to fetch code from mercurial's repositories Sep 08 19:31:09 without the need to have mercurial installed on the host Sep 08 19:31:09 Signed-off-by: Eric Bénard Sep 08 19:31:47 kergoth, image building now Sep 08 19:33:10 what is the best compiler directive to test if i am on arm < v6 ? Sep 08 19:33:22 I think I can fix the pulseaudio issue Sep 08 19:38:47 eFfeM: for pulseaudio, I think the asm in the file is using armv6 instructions Sep 08 19:40:12 ericben: I know Sep 08 19:40:39 you want to rewrite it in asam or bypass it when using arm < v6 ? Sep 08 19:41:46 Isn't the right answer here a runtime trick? Sep 08 19:42:02 bypass, actually the bypass is already there it is just the code that fails to compile Sep 08 19:42:07 cpu-arm.c says: Sep 08 19:42:08 if (flags & PA_CPU_ARM_V6) Sep 08 19:42:08 pa_volume_func_init_arm (flags); Sep 08 19:42:28 and this function registers the volume handler, so for v4 and v5 the code is not called Sep 08 19:42:31 yes, but the code is present and the assembler failss Sep 08 19:42:47 I searched for such a directive last week and didn't find it Sep 08 19:42:51 Should the assembler really be failing? Sep 08 19:43:01 that is why I need something like #ifdef __ARM_ARCH_5T__ Sep 08 19:43:19 but was not sure if there is a better thing (and I would need something form V4 too Sep 08 19:43:44 That's going the wrong direction Sep 08 19:43:47 the asm is failing because the target is armv5 and the asm is an armv6 instruction, the asm rejects that if target is armv5 Sep 08 19:43:48 Why is the compile failing? Sep 08 19:44:02 Then how does other stuff work? Sep 08 19:44:03 Tartarus: when using optimized flags for armv4 or v5 I think the asm won't accept armv6 instructions Sep 08 19:44:28 * Tartarus pulls out git log Sep 08 19:44:51 khem, read this thread: http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/023811.html Sep 08 19:45:05 s/khem/Tartarus/ Sep 08 19:45:10 oopsie Sep 08 19:45:13 from what I searched lasat week, it appears other peoples cross compiling have this problem Sep 08 19:45:41 I don't mean pulseaudio I mean other projects Sep 08 19:45:43 pulseaudio has inline armv6 code, no way a v5 is going to choke that Sep 08 19:46:59 s/choke/process/ Sep 08 19:47:04 so it will choke if compiled Sep 08 19:47:09 eFfeM: yes you need to check for defines which identify arches Sep 08 19:47:26 How does pixman do this? Sep 08 19:47:41 the arch is not a number which can be compared less than or greater than Sep 08 19:47:48 i'd hoped to find something like arm_arch or so, but it seems not to be there Sep 08 19:49:42 qt is using : __TARGET_ARCH_ARM >= 6 Sep 08 19:49:53 thats not a gcc define Sep 08 19:50:06 you can come up with something like that Sep 08 19:50:11 for pulseaudio Sep 08 19:51:08 khem: yes I see that's for arm's compiler sorry Sep 08 19:51:16 Tartarus: pixman does not seem to use armv6 instructions, mostly mov and and and or etc Sep 08 19:52:03 oh, I can pass a -D flag with ARCH or so and use that, i was hoping there was a cleaner/more portable way Sep 08 19:54:29 #if (!defined (__ARM_ARCH_4T__) && !defined (__ARM_ARCH_5__)&& !defined (__ARM_ARCH_5T__)) Sep 08 19:54:51 you need to add others too which covers arches below v6 Sep 08 19:55:02 yeah Sep 08 19:55:07 no idea how to get afull list Sep 08 19:56:16 re Sep 08 19:56:38 eFfeM : ./include/opcode/arm.h in binutils Sep 08 19:56:42 eFfeM: well do for what its failing for up Sep 08 19:56:45 us Sep 08 19:56:58 why do you want a comprehensive solution Sep 08 19:57:00 now Sep 08 19:57:18 if it fails for someother arch then this check can be enhanced as we go Sep 08 20:00:08 be easier just to add armv7 and armv6 then all the arches < armv6 Sep 08 20:00:18 and more intuitive to fix in future Sep 08 20:00:46 khem true Sep 08 20:01:52 XorA: well for an old arch it will break, a patch for v6/v7 will silentl give the C behaviour for say armv8 Sep 08 20:02:28 eFfeM: no guarantees that future arms wont deprecate instructions anyway Sep 08 20:02:38 ture Sep 08 20:02:41 true Sep 08 20:03:06 I was just thinkint he lazy was as I think there is armv6 armv7 armv7-a less typing :-) Sep 08 20:04:25 I could be wrong Sep 08 20:04:37 eFfeM: the full list : https://wiki.edubuntu.org/ARM/Thumb2PortingHowto Sep 08 20:05:00 XorA: usually instruction deprecation happens rarely Sep 08 20:05:28 XorA: here its using opcodes which are in armv6 and above Sep 08 20:05:37 I think it will be valid for a while Sep 08 20:05:47 before armv6 is deprecated Sep 08 20:05:57 ericben: thanks, Sep 08 20:06:02 will give this a try tomorrow Sep 08 20:06:03 cya Sep 08 20:14:20 damn it, util-linux-ng-native looks to be having ncurses issues Sep 08 20:14:39 anyone who commits and does builds with assume_provided should be shot ... Sep 08 20:15:32 anyone using bitbake 1.10.0? getting started still references 1.8.18 and I'm wondering if there are issues with 1.10? Sep 08 20:15:44 1.10 is fine here Sep 08 20:15:57 already been a few fixes for a 1.10.1 but i don't think they were critical Sep 08 20:16:05 for common cases anyhow? heh Sep 08 20:17:25 no big issues that i know of Sep 08 20:17:51 is anyone actively trying to fix the ncurses-native problems? Sep 08 20:18:07 hmm... I must be doing something silly then - getting a slew of 'ERROR: name 'oe' is not defined while parsing ... Sep 08 20:18:08 Crofton_|work: yes enrico is doing so Sep 08 20:18:28 util-linux-ng is failing for me Sep 08 20:18:36 What dist? Sep 08 20:19:05 building Angstrom-2010 on Fedora er 11/ Sep 08 20:19:11 updating my own angstrom derived distro - resync'ing with upstream OE - must have missed something Sep 08 20:19:15 no Fedora 13 Sep 08 20:19:39 tharvey: which version of bitbake Sep 08 20:19:51 tharvey, hm, don't get that here with either 1.10 or master. what python version? Sep 08 20:20:33 bitbake 1.10.0, python 2.6.5 Sep 08 20:22:46 Crofton_|work: which ncurses-native problems? Sep 08 20:22:56 the widec or -ltinfo ones? Sep 08 20:24:00 | /usr/bin/ld: note: 'LINES' is defined in DSO /home/balister/oe/tmp/sysroots/x86_64-linux/usr/lib/libtinfo.so.5 so try adding it to the linker command line Sep 08 20:24:16 from util-linux-ng-native Sep 08 20:27:26 are there '--no-add-needed' linkerflags? Sep 08 20:27:35 Crofton_|work: and you dont have ncurses-native in ASSUME_PROVIDED Sep 08 20:27:52 no Sep 08 20:28:06 ensc: what does that mean Sep 08 20:28:19 I don't use ASSUME_PROVIDED Sep 08 20:28:58 at least fedora adds -Wl,--no-add-needed to linker flags which breaks builds implying the opposite behavior Sep 08 20:29:51 e.g. when 'libncurses' is linked against libtinfo, your program uses a libtinfo feature, you can write 'gcc my-prog.o -lncurses' with --add-needed Sep 08 20:29:59 ah you mean --copy-dt-needed-entries Sep 08 20:30:26 ah yes, that's the new name Sep 08 20:31:31 you can use these flags Sep 08 20:31:35 sure Sep 08 20:32:01 --no-copy-dt-needed-entries -ltinfo --copy-dt-needed-entries Sep 08 20:32:21 ... or add -ltinfo to the linker line ;) Sep 08 20:33:23 yeah Sep 08 20:33:51 so what is the incantation to fix util-linux-ng-native? Sep 08 20:38:31 Crofton_|work: You could add LDFLAGS += "-Wl,--no-copy-dt-needed-entries -lncurses -Wl,--copy-dt-needed-entries" to util-linux-ng-native Sep 08 20:38:47 or LDFLAGS += "-ltinfo" Sep 08 20:38:57 both should work hopefully Sep 08 20:39:23 yes; setting this in the NCURSES_LIBS="-lncurses" in configure.ac should work Sep 08 20:39:39 explicit -ltinfo is bad because it breaks with ncurses-5.4 Sep 08 20:39:39 ok, looking Sep 08 20:39:55 pkgoconfig --libs ncurses does not work with 5.4 either Sep 08 20:40:04 this is a BBCLASSEXTEND recipe Sep 08 20:40:32 LDFLAGS_virtcvlass-native? Sep 08 20:40:57 should work both for target and native Sep 08 20:41:38 testing Sep 08 20:41:49 target might not affected because it does not have the implicit --no-add-needed Sep 08 20:42:02 Crofton_|work: are you using fedora? Sep 08 20:42:08 yes Sep 08 20:42:10 F13 Sep 08 20:42:52 f13 has these linkerflags enabled by default Sep 08 20:46:47 /usr/bin/ld: cfdisk.o: undefined reference to symbol 'LINES' Sep 08 20:46:47 | /usr/bin/ld: note: 'LINES' is defined in DSO /home/balister/oe/tmp/sysroots/x86_64-linux/usr/lib/libtinfo.so.5 so try adding it to the linker command line Sep 08 20:46:47 | /home/balister/oe/tmp/sysroots/x86_64-linux/usr/lib/libtinfo.so.5: could not read symbols: Invalid operation Sep 08 20:46:48 ah.. f13 made libncurses.so a linker script with INPUT(libncurses.so.5 -ltinfo) so they do not see it here Sep 08 20:48:02 what's are the linker flags? libtool/automake probably mangled them so that '-Wl,... -l... -Wl,...' became '-Wl,... -Wl,... -l...' Sep 08 20:48:05 Crofton_|work: whats your build os Sep 08 20:48:17 F13 Sep 08 20:51:51 I will make libncurses.so a linkerscript with INPUT(libncurses.so.5 AS_NEEDED(-ltinfo)) Sep 08 20:52:02 so no need to touch util-linux-ng Sep 08 20:52:09 but not today... Sep 08 20:52:37 tomorrow? Sep 08 20:52:48 yes; I hope Sep 08 21:59:42 r Sep 08 21:59:43 ee Sep 08 21:59:46 is there a way to prevent creation of empty dev and dbg packages? Sep 08 22:04:05 you shouldn't. it'll break deps between -dev packages Sep 08 22:04:16 oh, ok Sep 08 22:04:33 my bbclass is working out just fine btw, thangs again for the help yesterday Sep 08 22:06:42 s/thangs/thanks/g Sep 08 22:08:43 np Sep 08 22:23:46 mmh... staging fails when a package upgrade replaces a symlink with a regular file :( Sep 08 22:38:10 03Khem Raj  07org.openembedded.dev * r52d4cb1290 10openembedded.git/recipes/xalan-j/xalan-j_2.7.1.bb: Sep 08 22:38:11 xalan-j_2.7.1.bb: Add missing quote to the HOMEPAGE string Sep 08 22:38:11 Signed-off-by: Khem Raj Sep 08 23:07:38 hello Sep 08 23:08:00 i make'd a opie-image but the colours are wrong ! Sep 08 23:36:22 angelox_123: colors are wrong in what way Sep 08 23:36:26 is there any pattern Sep 08 23:37:38 the feng shui is off? Sep 08 23:38:51 :) Sep 08 23:39:07 khem: it's something to do with the screen on the motorola a1200... it's 18bpp Sep 08 23:39:21 ah heh Sep 08 23:39:47 bluelightning: are you in bay area ? Sep 08 23:39:49 there's a patch for qte floating around, it no longer applies with all of the other patches we have in OE... I tried to hack it but with it applied Opie won't start apparently Sep 08 23:40:13 I don't have an a1200 so I can't really debug it Sep 08 23:40:29 yes only show the black screen that shows before start opie..but don't start! Sep 08 23:40:31 khem: no, I'm living in London (used to be in NZ a couple of years ago) Sep 08 23:40:59 oh thats far Sep 08 23:41:51 How is NZ are there jobs for hi-tech folks Sep 08 23:42:52 I'm not sure, I haven't been looking for jobs there for a while... but I know the job market was hit there as everywhere else unfortunately Sep 08 23:43:05 hmm Sep 08 23:43:11 I do know at least one firm that is expanding though so it can't be all bad Sep 08 23:43:34 you fancy a change of scenery? Sep 08 23:43:47 not really Sep 08 23:44:00 but its good to know Sep 08 23:44:37 you're in S.F. yourself I assume? Sep 08 23:45:07 I am in San Jose Sep 08 23:45:14 ah ok Sep 08 23:45:15 its like 30 miles Sep 08 23:45:17 any help? Sep 08 23:46:18 angelox_123: you will probably need to debug it yourself I'm afraid, as doing so requires the device Sep 08 23:46:29 ok thanks Sep 08 23:46:57 angelox_123: maybe put the patch back, enable Opie debugging (there's a page on the opie site that tells you how to do that) and then view the log file Sep 08 23:47:11 after booting the device to the black screen that is Sep 08 23:47:32 it's easier if you can get shell access on the device of course Sep 08 23:47:40 by serial or similar Sep 08 23:48:10 ssh Sep 08 23:48:23 yep, if you have network that's even better :) Sep 08 23:48:38 i'll try Sep 08 23:48:42 thank'you Sep 08 23:49:05 but i think the problem is with QT/E Sep 08 23:49:11 once you get that set up you can always add more debug messages into qte code to determine where it is getting to Sep 08 23:49:21 yes, since the patch is applied against qte I agree Sep 08 23:49:39 the patch must have worked for someone though Sep 08 23:52:44 off-topic : english noob ask: what is AFAIK ? Sep 08 23:52:58 'as far as I know' Sep 08 23:53:08 thanks Sep 08 23:53:09 np Sep 09 00:38:14 grg: hi Sep 09 00:38:23 khem, yo Sep 09 00:38:39 grg: now bitbake world is parsable Sep 09 00:38:48 ooooh Sep 09 00:38:49 grg: I know you have a powerful machine Sep 09 00:38:54 :) Sep 09 00:39:03 so when it has some free cycles give it a shot Sep 09 00:39:09 can do Sep 09 00:39:30 there are 82500 tasks dont be intimidated Sep 09 00:40:13 you can do it for whatever distro/machine combo you use Sep 09 00:40:45 my laptop has been churning bits for over 16 hrs now Sep 09 00:40:51 i'm just reading docs today anyway. I'm sure the workstation needs some exercise Sep 09 00:41:04 cool Sep 09 00:41:34 you can also do bitbake -k world and save the results Sep 09 00:41:39 and see what all fails Sep 09 00:42:43 khem, whatever happened to the cooker.log file? Sep 09 00:43:04 that was bitbake master Sep 09 00:43:33 ive just done a git pull in my bitbake and oe trees Sep 09 00:44:08 so there will be no massive log file stored somewhere? I have to pass the output of bitbake through tee or something? Sep 09 00:45:59 yeah Sep 09 00:46:23 bitbake -k world | tee world.log Sep 09 00:46:41 yup, i just kicked that off Sep 09 00:46:53 with 'time' out the front Sep 09 00:47:02 i hate it when i forget to time long jobs Sep 09 00:50:14 thats good. Sep 09 00:50:19 what distro/machine ? Sep 09 00:51:40 khem, qemumipsel/minimal Sep 09 00:51:50 ok nice Sep 09 00:51:58 I do it on arm/minimal Sep 09 00:52:42 i'm sure i'll get more failures than for arm Sep 09 00:52:57 there's a lot of omap only stuff around Sep 09 00:53:25 hmmm... hope i don't smash my workplace net quota... Sep 09 00:53:58 khem, how big is your sources dir? Sep 09 00:56:56 grg, are you working on omap? Sep 09 00:57:06 ka6sox, no. mipsel Sep 09 00:57:37 have played with beagleboard in the past, not recently though Sep 09 00:58:37 oh, understood. Sep 09 00:59:40 khem, i have 64886 tasks Sep 09 01:06:24 grg: you dont have rm_work enabled do you ? Sep 09 01:06:33 nope Sep 09 01:06:39 thats why Sep 09 01:08:39 khem, i have 130gb free on my tmp dir, am i likely to fill my drive without rm_work? Sep 09 01:08:48 grg: most likely Sep 09 01:09:04 hmm Sep 09 01:09:49 grg: I would suggest add this Sep 09 01:09:55 INHERIT += "insane sanity angstrom-mirrors recipe_sanity testlab devshell rm_work" Sep 09 01:10:04 to your local.conf Sep 09 01:12:51 khem, here's my local.conf http://pastebin.ca/1936217 - anything else i should change before i restart? Sep 09 01:14:50 grg: also add Sep 09 01:14:52 QA_LOG = "1" Sep 09 01:15:06 PSTAGING_DISABLED = "1" Sep 09 01:15:45 somehow pstaging and staging_qa did not go well wth rm_work Sep 09 01:15:55 when one restarted the build Sep 09 01:16:01 so just disable it Sep 09 01:16:03 if not used Sep 09 01:16:24 ok Sep 09 01:16:37 i suppose i should check if i've got any local commits too... Sep 09 01:16:52 I dont think you need TARGET_FPU = "soft" Sep 09 01:17:07 thats ok Sep 09 01:17:24 your local commits need to validate with bitbake world anyway Sep 09 01:17:27 :) Sep 09 01:18:45 yes, but chances are my changes fix things that are broken, but in less than ideal ways Sep 09 01:19:23 TARGET_FPU=soft should be faster than using the kernel fpu emulation, at least on mips Sep 09 01:19:42 (so i read on the mipslinux mailing list once upon a time) Sep 09 01:23:02 thats true Sep 09 01:23:41 for qemu it does not matter Sep 09 01:25:14 i actually don't run inside qemu at all Sep 09 01:25:49 hey. why is prefix=/usr instead of / when staging an install? Sep 09 01:26:36 CMoH, binaries and libraries generally get installed in /usr/lib and /usr/bin, not /lib and /bin Sep 09 01:27:10 CMoH: you can choose to flatten the tree Sep 09 01:27:13 yeah, but shouldn't bindir, libexec and such take care of that? prefix should point to the root of the filesystem Sep 09 01:27:40 see micro.conf Sep 09 01:28:58 grg: ok cool if u have real hardware Sep 09 01:31:00 CMoH: no Sep 09 01:31:25 CMoH: the same packages are installed in / on hurd Sep 09 01:31:35 on lnx generally /usr is preferred Sep 09 01:32:27 yeah, i see; my mistake Sep 09 01:32:58 grg: did you restart the build Sep 09 01:33:09 khem, yep Sep 09 01:33:58 khem, when will oe support hurd? Sep 09 01:34:03 :P Sep 09 01:34:23 well, so how can i reach with prefix=/usr the folder /etc with cmake? Sep 09 01:38:29 bloody idiotic cmake Sep 09 01:40:58 is there any irc channel where it's safe to write AAARGHH Sep 09 01:43:35 grg: cool so how many task does it show now Sep 09 01:43:48 grg: and regarding hurd I believe never Sep 09 01:43:55 82357 Sep 09 01:44:02 same as me Sep 09 01:44:16 did hurd ever fix that 2gb partition size limit? Sep 09 01:52:25 grg: you will need this patch Sep 09 01:52:27 http://pastebin.com/CJc0vMxp Sep 09 01:52:50 this lot of TI stuff is weird licence Sep 09 01:52:59 not really convenient Sep 09 01:53:45 khem, shouldn't it be excluded because i'm not building for a COMPATIBLE_MACHINE? Sep 09 01:53:59 ah could be Sep 09 01:55:54 grg: my machine was not in compatible machines but it still poopoo'ed on me Sep 09 01:56:19 i suppose since we have the same number of tasks that the tasks are going to be the same Sep 09 01:57:34 well keep going and see what all breaks Sep 09 01:57:48 you are using bitbake -k anyway Sep 09 01:58:14 this should fails and sit in a corner still bitbake world will progress **** ENDING LOGGING AT Thu Sep 09 02:59:57 2010