**** BEGIN LOGGING AT Fri Sep 11 03:00:00 2009 Sep 11 03:41:01 q Sep 11 04:54:24 anyone try building >= gnupg-1.4.10? Sep 11 05:56:00 is http only way to set feeds for opkg Sep 11 05:58:45 I would like to replace the initscripts with a modified version, how should I do it? Sep 11 05:59:04 I copied and renamed the recipe into my overlay, defined IMAGE_INITSCRIPTS in my image recipe. Sep 11 05:59:24 But now my image gets installed both the original and modified version of the scripts. (installed-packages.txt) Sep 11 06:31:02 good morning Sep 11 06:33:58 good morning Sep 11 07:07:04 03Koen Kooi  07org.openembedded.dev * r2b1928ff76 10openembedded.git/recipes/tasks/task-sdk-native.bb: task-native-sdk: fix upgrade paths after task renaming Sep 11 07:07:15 03Koen Kooi  07org.openembedded.dev * rd13e15663f 10openembedded.git/recipes/linux/ (4 files in 2 dirs): linux-omap: add 2.6.31 Sep 11 07:20:19 good morning Sep 11 07:20:31 morning mckoan ! Sep 11 08:01:48 on building glibc_2.9 i got a: Sep 11 08:01:50 configure: error: C preprocessor "arm-angstrom-linux-gnueabi-gcc -E" fails sanity check Sep 11 08:01:58 any ideas? Sep 11 08:23:28 good moring Sep 11 08:23:38 de_manuel_pi: yes... a bug Sep 11 08:23:52 de_manuel_pi: this seems to happen recompiling glibc Sep 11 08:24:42 clean glibc gcc-cross glibc-initial gcc-cross-intermediate and gcc-cross-initial Sep 11 08:25:01 that's the workaround - it takes some time... Sep 11 08:25:50 thanks! doing so seems to work :)) Sep 11 08:57:36 03Koen Kooi  07org.openembedded.dev * r0ec2fb9837 10openembedded.git/contrib/angstrom/sort.sh: angstrom feed sorter: add shiva support Sep 11 08:57:38 03Koen Kooi  07org.openembedded.dev * r7937ed35de 10openembedded.git/ (13 files in 4 dirs): Sep 11 08:57:38 x-load: add omap3517-evm support Sep 11 08:57:38 * 1.41 still has the volatile bugs when compiled with non CSL stuff Sep 11 08:57:39 03Koen Kooi  07org.openembedded.dev * rede46c7614 10openembedded.git/recipes/linux/ (3 files in 3 dirs): linux-omap-psp 2.6.29: add WIP patch for EHCI support Sep 11 08:57:42 03Koen Kooi  07org.openembedded.dev * r4c01483355 10openembedded.git/recipes/linux/ (3 files in 3 dirs): linux-omap-psp 2.6.29: add shiva support Sep 11 08:57:49 03Koen Kooi  07org.openembedded.dev * rd0585b86dd 10openembedded.git/conf/machine/omap3517-evm.conf: omap3517-evm: add machine file Sep 11 08:57:50 03Koen Kooi  07org.openembedded.dev * r7286737587 10openembedded.git/ (18 files in 3 dirs): u-boot git: add support for omap3517-evm Sep 11 09:00:22 gm Sep 11 09:23:19 wargg now i get some errors on locales, i add them to the ignore list in glibc packages but it seems there are a lot of them :( Sep 11 09:23:51 is it possible to build glibc with just a defined list of locales? Sep 11 09:25:50 I don't think so, though it'd be fairly straightforward to modify the recipes to make that possible. Sep 11 09:28:41 hmm trial and error :) Sep 11 09:29:20 hi Sep 11 09:30:05 hi pb__, hi woglinde Sep 11 09:30:09 he florian Sep 11 09:30:16 hm so next task Sep 11 09:30:18 gettext again Sep 11 09:34:26 florian: good morning Sep 11 09:39:09 gm woglinde , pb_, florian Sep 11 09:39:59 he likewise Sep 11 09:40:42 hi likewise Sep 11 09:52:24 When installing OE after making the git and try "sudo bitbake" I got the following error: http://pastebin.com/m5a1fae3f any ideas? Sep 11 09:57:24 julemore: http://wiki.openembedded.net/index.php/Getting_started Sep 11 10:02:12 yeah thats the guide I was following Sep 11 10:02:38 and followed all the steps till bitbake nano Sep 11 10:04:14 why did you decide to run bitbake under sudo? the guide doesn't suggest that, as far as I remember. Sep 11 10:04:44 because if I dont sudo permission error is raised Sep 11 10:05:21 eeeeks Sep 11 10:05:24 dont use root Sep 11 10:05:27 sounds like you should correct the permissions on whatever file is causing that issue. Sep 11 10:05:33 I accidently built an rpm as root once Sep 11 10:05:39 running bitbake under sudo is really not a good idea. Sep 11 10:05:41 and successfully did a rm -rf / Sep 11 10:06:01 I learnt to double check which window I used since then Sep 11 10:06:44 heh, I am surprised that zecke hasn't added os.system("rm -rf /") to insane.bbclass by now :-} Sep 11 10:07:20 Hi, I am getting compiler Badness when I try to compile Sep 11 10:07:24 how can I fix that? Sep 11 10:07:26 when not using sudo: http://pastebin.com/mb66ee5a Sep 11 10:07:28 i am on dev now Sep 11 10:08:01 julemore: so, you need to correct the permissions on /stuff/build/tmp Sep 11 10:08:08 julemore: fix this : permission denied: '/stuff/build/tmp' Sep 11 10:08:20 julemore: show us ls -ald /stuff/build/tmp Sep 11 10:08:36 omg sorry Sep 11 10:08:43 tmp dir doesnt exists... Sep 11 10:08:50 but its the same Sep 11 10:09:06 if I use bitbake in /stuff/build Sep 11 10:09:11 i got the same error as before Sep 11 10:09:22 but now I dont need to use sudo Sep 11 10:09:52 chown -R $USER:$USER /stuff Sep 11 10:09:59 sudo chown -R $USER:$USER /stuff Sep 11 10:10:03 is most liely the fix Sep 11 10:10:45 http://pastebin.com/m5c288480 Sep 11 10:11:01 for the error above? Sep 11 10:12:15 so, that error is generally a symptom of BBPATH being set wrong (or not at all) Sep 11 10:12:28 hmmm Sep 11 10:13:06 specifically, it usually means that bitbake isn't able to find the main bitbake.conf file, which lives in org.openembedded.dev/conf Sep 11 10:16:05 omg pb u got reason... but I dont understand that BBPATH var was here the other day.... Sep 11 10:16:20 * julemore kills me Sep 11 10:16:25 :) Sep 11 10:16:32 heh Sep 11 10:17:44 well now i got other errors.... Sep 11 10:18:02 in that step... before bitbake nano... can I bitbak e gcc-cross? Sep 11 10:20:20 http://pastebin.com/m5ce1fd35 Sep 11 10:23:11 what sholud I do for creating a tool-chain? bitbake gcc-cross? what os version will be the gcc-cross toolchain? where do u specifu that? Sep 11 10:30:21 hey Sep 11 10:30:31 can anyone just tell me what to do in this Sep 11 10:30:44 Unknown Event: ['bb.event.NoProvider', {'_runtime': False, '_data': None, '_item': 'hildon-lgpl', 'pid': 0, 'data': None}] NOTE: Runtime target 'libgpepimc-hildon' is unbuildable, removing... Missing or unbuildable dependency chain was: ['libgpepimc-hildon', 'hildon-lgpl'] ERROR: Required build target 'maemo-angstrom-image' has no buildable providers. Missing or unbuildable dependency chain was: ['maemo-angstrom-image', 'libgpepimc-hildo Sep 11 10:31:37 anyone please Sep 11 10:31:40 ?? Sep 11 10:32:38 that means there is a dependency missing Sep 11 10:33:10 I think that hildon-lgpl is missing Sep 11 10:34:16 hi archae0pteryx Sep 11 10:34:47 eww hildon recipes dont follow style guide in bad way Sep 11 10:35:11 ok Sep 11 10:35:14 I think the hildon recipes pre-date the style guide by some time. Sep 11 10:35:43 pb__: most likely, but they hurt my eyes :-) Sep 11 10:35:47 heh Sep 11 10:37:01 ah yes, hildon-lgpl is moved into nonworking as it doesnt compile Sep 11 10:37:14 as is a lot of maemo stuff Sep 11 10:37:47 tio: prepare to work on uograding/fixing maemo or give up now is your two options Sep 11 10:38:35 so i should remove dat Sep 11 10:38:36 ? Sep 11 10:41:16 tio: do you want a maemo version of angstrom, or did you just randomly pick an image? Sep 11 10:41:45 maemo version of angstrom Sep 11 10:41:55 tio: then you will need to fix the recipes Sep 11 10:42:39 all the recipes containing the hildon-lgpl Sep 11 10:42:45 tio: I can't remember the guys name but there was a GSoC student who worked on Maemo5 OE recipies, ok, not Angstrom specific but may be of use. It was working last time I tried but was limited. Sep 11 10:43:12 ok Sep 11 10:43:13 NOTE: generating locale en_US (UTF-8) Sep 11 10:43:13 FATAL: kernel too old Sep 11 10:43:19 i got no luck today Sep 11 10:43:21 tio: I suspect that angstrom image is trying to use old stuff, I notice maemo4 should build Sep 11 10:43:39 i neeed to build maemo 5 though Sep 11 10:44:17 need to find that GSoC then :-D Sep 11 10:45:39 tio: yep, I don't think all of the GSoC GIT tree is in mainline OE yet. Sep 11 10:46:23 ohh Sep 11 10:46:25 :( Sep 11 10:46:45 tio: http://github.com/rkirti/maemo_angstrom/tree/master IIRC and http://wiki.maemo.org/GSoC_2009/Projects/Integrating_Maemo_in_Open_Embedded Sep 11 10:47:04 DJWillis: maemo on pandora then? Sep 11 10:47:15 cute idea... Sep 11 10:47:47 XorA: I have had it going ;-) and Mer, seems to work well (well not really a shock considering the base for the N900 ;-)). Sep 11 10:48:04 you got Mer working??? Wow!!!!!! Sep 11 10:48:18 XorA: for now, still E17 images for the most part and I am working on XFCE4.6 recipies in my free time to try and get that going. Sep 11 10:48:39 everytime I try Mer on my n810 is corrupts itself on first reboot Sep 11 10:49:16 XorA: not fully, but there is not a lot of hacking required. I am just not so keen on the Ubuntu based distro, I would rather build from recipies in OE and get it optemised as I want. Sep 11 10:50:12 of course one day their might be hardware to run your hard work on :-) Sep 11 10:50:31 XorA: don't even go there ;-) Sep 11 10:50:50 DJWillis: your still ahead of OpenMoko, just :-D Sep 11 10:51:16 XorA: ;-), that is so not a good project to be compaired with ;-) Sep 11 10:54:35 DJWillis: just dont let the CEO want a ray traced GUI and you should be ok :-D Sep 11 10:55:36 XorA: I think it's well known that the GUI people get is the one I bake in the images, and as I am not paid, that will be pretty stock and suit me ;-) Sep 11 11:09:13 i'm really stuck regarding this hildon-lgpl thing Sep 11 11:09:18 dunno wat to do ahead Sep 11 11:09:33 can anyone guide me? Sep 11 11:12:35 How do I add usb-massstorage modules to an already existing kernel? Sep 11 11:16:44 re Sep 11 11:17:00 julemore: be sure to follow the GettingStarted instructions "to the letter", i.e. very carefully and you should be fine. Sep 11 11:17:10 ~seen rkirti Sep 11 11:17:13 rkirti is currently on #maemo (2h 12m 26s) #oe (2h 12m 26s). Has said a total of 1 messages. Is idling for 1h 28m 26s, last said: 'heh'. Sep 11 11:18:07 03Klaus Kurzmann  07shr/import * r8cd9f7e031 10openembedded.git/recipes/gpe-sketchbook/gpe-sketchbook_0.2.9.bb: Sep 11 11:18:07 gpe-sketchbook_0.2.9: add missing RDEPEND for gpe-icons Sep 11 11:18:07 Signed-off-by: Klaus Kurzmann Sep 11 11:26:57 Hi, I have a problem in building qt3 hello world app in OE. I check log.do_compile file and see that the compile command is invoked with arm-angstrom-linux-gnueabi-gcc. I think it has to arm-angstrom-linux-gnueabi-g++. In Makefile I have this definition: CXX = $(OE_QMAKE_CXX) Does anyone know where $OE_QMAKE_CXX is defined, or how I find it out? Sep 11 11:30:52 munzur why you need qt3? Sep 11 11:32:20 Well, we have an application built with qt3 targeting i386 arch. So I'm trying to see if we can port it to BeagleBoard. Sep 11 11:37:44 better port it to qt4 Sep 11 11:38:04 qt3 support wasnt tested for a long time Sep 11 11:41:34 woglinde: I know, this a solution, but it's hard to port this app to qt4. So before doing it, better we check qt3 way. Sep 11 11:44:13 how many lines of code Sep 11 11:44:15 ? Sep 11 11:44:42 closed source? Sep 11 11:46:29 hm Sep 11 11:46:43 The source is closed, approximately 100K lines of code, and I really don't know, how many of them are related to GUI. Sep 11 11:48:08 hm Sep 11 11:48:33 did you inhrerit qmake_base qt3x11 in your recipe? Sep 11 11:48:40 args inherit Sep 11 11:50:39 inherit qmake qt3x11 Sep 11 11:51:19 hm should work Sep 11 11:51:29 because qmake inherits qmake_base Sep 11 11:51:31 which sets Sep 11 11:51:40 export OE_QMAKE_CXX="${CXX}" Sep 11 11:52:19 and CXX is normaly set to the cross-compile g++ Sep 11 11:53:41 I suppose so. Maybe my qmake_base is corrupted somehow. Sep 11 11:53:55 hm why? Sep 11 11:55:58 How can I check it? Sep 11 11:57:52 hm? Sep 11 12:00:19 check qmake_base, to see if it sets the right values. Sep 11 12:00:42 hm let me try something Sep 11 12:01:32 type bitake -i Sep 11 12:01:36 args bitbake Sep 11 12:01:40 getvar CXX Sep 11 12:03:00 or Sep 11 12:03:01 peek qt-x11-free OE_QMAKE_CXX Sep 11 12:03:45 BB>> getvar CXX Sep 11 12:03:45 ccache arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp Sep 11 12:04:28 args bitbake, is this a command? gave me an error. Sep 11 12:05:20 -i is the interactive shell Sep 11 12:05:32 for the `peek qt-x11-free OE_QMAKE_CXX´ it is parsing now. Sep 11 12:05:44 Yeah, i'm in this shell, now Sep 11 12:08:28 This is the result: ccache arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp Sep 11 12:08:34 yeah Sep 11 12:08:37 so all is fine Sep 11 12:12:48 In the Makefile, $(CC) is only used as: Sep 11 12:12:48 .c.o: Sep 11 12:12:48 $(CC) -c $(CFLAGS) $(INCPATH) -o $@ $< Sep 11 12:13:13 I don't have a .c file, and neither a .c.o Sep 11 12:13:28 hm is your Makefile dont provided to qmake and a .pro file? Sep 11 12:15:12 I got a .pro file, the Makefile is generated by that one. Sep 11 12:15:45 hm so it should work Sep 11 12:16:04 dont know if you need qmake2 for qt4 Sep 11 12:16:06 args Sep 11 12:16:08 qt3 Sep 11 12:16:11 maybee try this Sep 11 12:16:41 I don't have qt4 installed. Sep 11 12:16:44 woglinde: you asked for me ? Sep 11 12:16:57 I don't want to install it. Sep 11 12:16:58 rkirti *g* they discussed youtr gsoc Sep 11 12:17:16 woglinde: where ? Sep 11 12:17:22 scroll above Sep 11 12:17:29 ah ok Sep 11 12:17:42 yeah, I need to apply for OE git commit access Sep 11 12:17:59 hm I thought you already had Sep 11 12:18:06 Even in host machines, if qt4 and qt3 are both installed, the variables conflict Sep 11 12:18:22 let florian write the invitation mail Sep 11 12:18:25 I will ack them Sep 11 12:18:51 woglinde: Yeah I had it in a previous OE installataion. I installed a fresh OE to have only qt3. Sep 11 12:19:07 munzur hm Sep 11 12:20:29 woglinde: Thanks for your time and effort. If I find a solution, I'll share it. Sep 11 12:25:00 hi tmbinc Sep 11 12:30:47 pb_ : You mentioned "style guide" ..may I know what is that ? I was wondering if there are other provisions than sanity.bbclass to write sane and clean recipes .. I have quite a lot of mess in mine :( Sep 11 12:31:26 rkirti its in the wiki Sep 11 12:31:44 or manual Sep 11 12:32:09 http://wiki.openembedded.net/index.php/Styleguide Sep 11 12:32:51 woglinde: thanks Sep 11 12:32:53 but many recipes violate some Sep 11 12:33:01 ie mkdir and cp Sep 11 12:33:30 :-/ Sep 11 12:35:00 some should clean it up Sep 11 12:35:04 one Sep 11 12:36:20 hm Sep 11 12:36:36 what do I need to have in local.conf for qemu arm Sep 11 12:59:00 hi Sep 11 13:05:10 hi sushisan Sep 11 13:26:58 hi! I am working on a package, and I don't want bitbake to stop running if "make" fails. Is there a nice way to avoid this ? Sep 11 13:28:38 hm was there a way to include a common local.conf in local.conf? Sep 11 13:29:53 bitbake --help Sep 11 13:29:55 bitbake -k Sep 11 13:31:16 woglinde: Thanks! but I need it just inside this package and not for my whole image for example. Sep 11 13:31:27 no way Sep 11 13:32:49 woglinde: I needed to include a common local.conf in the local.conf. My solution is to have a my_project.conf and a common.conf, and I use "cat" to write the files into local.conf Sep 11 13:33:10 saiimons hm there is another way Sep 11 13:33:14 but I didnt remeber Sep 11 13:35:53 woglinde: I'll try to see if "make -i" works for me Sep 11 13:38:47 woglinde: "make -i " did the job :D Sep 11 13:40:01 yeah Sep 11 13:40:05 hm ah Sep 11 13:40:17 I need only to set in bitbake.conf Sep 11 13:43:01 woglinde: ? I don't understand what you need to do with bitbake.conf Sep 11 13:43:31 not you Sep 11 13:43:35 for my problem Sep 11 13:44:12 about including a file in local.conf ? Sep 11 13:44:23 yes Sep 11 13:44:30 hm Sep 11 13:44:31 ah Sep 11 13:45:03 args Sep 11 13:45:05 so easy Sep 11 13:45:07 include Sep 11 13:45:12 morning Sep 11 13:45:13 include foo Sep 11 13:45:23 hi chouimat Sep 11 13:46:04 include works in local.conf ? Sep 11 13:46:17 sure Sep 11 13:46:26 its parsed in bitbake contents Sep 11 13:46:30 where include works Sep 11 13:46:31 *g* Sep 11 13:46:43 strange, last time I tried, it failed :/ Sep 11 13:59:48 he rp Sep 11 13:59:52 hi kgilmer Sep 11 13:59:55 ~seen pb Sep 11 13:59:57 pb was last seen on IRC in channel #tomcat, 322d 19h 16m 32s ago, saying: 'arghh'. Sep 11 13:59:57 hi woglinde Sep 11 14:00:07 ~seen pb_ Sep 11 14:00:08 pb_ is currently on #oe (22h 29m 4s), last said: 'well, I guess you should take it up with khem'. Sep 11 14:00:09 good morning woglinde RP Sep 11 14:00:52 woglinde: not enough underscores :-} Sep 11 14:01:04 hehe Sep 11 14:01:07 hi kgilmer Sep 11 14:01:25 pb hm I would like to rease the linux-libc-headers for micro Sep 11 14:01:29 rase Sep 11 14:01:32 args raise Sep 11 14:01:44 2.6.29 or even 2.6.30 Sep 11 14:01:48 righto, I don't think that should be a problem Sep 11 14:03:14 okay Sep 11 14:03:20 will commit it this evening Sep 11 14:03:40 ok, cool Sep 11 14:04:12 I am working now on gettext again Sep 11 14:04:25 I'm going to bump up the toolchain versions as well, since khem's test results for gcc 4.4.1 seem good. Sep 11 14:04:39 hm can you wait? Sep 11 14:04:48 for the headers Sep 11 14:05:06 or making it yourself Sep 11 14:05:19 I can wait if you prefer. The two changes shouldn't have any impact on each other though. Sep 11 14:05:42 yeah Sep 11 14:05:48 Send me a note when your headers change is in, and I'll commit the other version changes at the same time. Sep 11 14:05:57 er, s/at the same time/afterwards/ Sep 11 14:06:03 hm it should fix the udev-uclibc 141 problem with poll stuff right? Sep 11 14:06:16 given a new enough kernel and uclibc, yes. Sep 11 14:06:19 hm I will test it Sep 11 14:06:29 did that patch reach 2.6.31 kernel? Sep 11 14:06:33 obviously your kernel needs to actually support ppoll(), but if you have that then it should be ok. Sep 11 14:06:40 I thought it was in 2.6.32 queue Sep 11 14:06:47 oh Sep 11 14:06:48 okay Sep 11 14:06:56 Xora I thought it went earlier Sep 11 14:07:18 why console image builds x Sep 11 14:07:20 hm hm Sep 11 14:07:27 I got impression from arm-linux it missed the window, maybe not Sep 11 14:07:48 some crazy dependency chain. might be bluez again maybe. Sep 11 14:08:00 thats not good Sep 11 14:09:12 BTW can we turn off all localisation in OE? Sep 11 14:09:30 USE_NLS = "0" Sep 11 14:09:41 and provide all recipes inherit gettext Sep 11 14:09:49 ask koen why glib needs NLS stuff Sep 11 14:10:06 fix all packages which use the sucking gnome nls support Sep 11 14:10:19 * XorA can probaly get away without gnome Sep 11 14:11:01 aeh Sep 11 14:11:27 some packages using localized stuff provided from gnome-macros Sep 11 14:11:30 and they suck Sep 11 14:11:49 they dont know the turn of nls configure line Sep 11 14:11:58 so building po files is always on Sep 11 14:12:05 dbus again Sep 11 14:12:08 dbus suckz Sep 11 14:12:28 yeah bluez depends an dbus Sep 11 14:12:29 building po files sounds fairly harmless, that doesn't exactly take a long time. Sep 11 14:12:50 so long as the gnome bits don't cause libintl to get hauled in then there shouldn't be too much of an issue. Sep 11 14:13:00 why the hack bluez depends on dbus-glib Sep 11 14:13:15 for the pincode stuff, I think Sep 11 14:13:32 that's only bluez-apps, though. the libs shouldn't need dbus. Sep 11 14:13:34 or indeed glib Sep 11 14:13:35 but this drags in all the suckong stuff Sep 11 14:13:46 I will fix it later Sep 11 14:13:57 now we have to buy new shoes for my son Sep 11 14:13:59 till later Sep 11 14:14:06 dbus itself shouldn't drag in too much else, it's fairly self contained. Sep 11 14:14:19 if you're getting gnome then that sounds more like gstreamer, which bluez also (hilariously) depends on Sep 11 14:14:34 only apps though, again. stick to bluez-libs and you should be ok Sep 11 14:14:40 woglinde: enjoy Sep 11 14:15:21 yeah gstreamer is in too Sep 11 14:15:48 gst-plugins-base Sep 11 14:16:09 right Sep 11 14:16:20 this is, as they say, teh suck Sep 11 14:16:45 hm Sep 11 14:16:55 ah thats the bluez3 vs. bluez4 think Sep 11 14:17:24 it's a bit worse because the bluez4 recipe, which is favoured by 4ng5tr0m at least, gloms apps and libs back together so you can't even build the libraries without hauling in all of gnome. Sep 11 14:17:48 should really split that back apart again for micro, it's a pain. Sep 11 14:18:16 yepp I will do it Sep 11 14:18:19 I like pain Sep 11 14:18:20 haha Sep 11 14:18:49 I posted a half-done patch for that to the list a while back, you could use that as a place to start. Sep 11 14:19:09 I think kergoth might have bashed at it a bit too but I don't quite remember where he got to Sep 11 14:19:10 okay Sep 11 14:19:16 okay will ask him Sep 11 14:20:17 there is a bluez4-libs.inc which is never instantiated :-) Sep 11 14:20:35 oh there it is Sep 11 14:20:40 pb_, woglinde about bluez4, it does not depend on dbus just for pincode. all the bluez api is now dbus Sep 11 14:21:04 a2dp, headset, etc Sep 11 14:21:12 ah right Sep 11 14:30:45 anyone use xterm in oe? Sep 11 14:30:49 * RP wonders how to resolve the layout_ variable mess :/ Sep 11 14:30:51 I've got the problem that copy/paste is not working Sep 11 14:31:59 xterm? heh, that's a bit retro. do you mean the x clipboard isn't working when you middle-click, or something else? Sep 11 14:32:02 RP: a rare five minutes for you here :-D Sep 11 14:32:49 XorA: indeed. I've opted to spend some time trying to sort out the sdk/canadian mess in Poky and probably need some moral support :/ Sep 11 14:33:04 pb__, yes thats what I mean :) Sep 11 14:33:06 * XorA gets his pom poms and cheers on RP Sep 11 14:33:24 it also doesn't work in midori and xclipboard doesn't show anything so I'm guessing it's a system-wide issue Sep 11 14:33:26 th1_: does it work in other applications? Sep 11 14:33:29 ah, right Sep 11 14:33:53 My current dilemma is how you deal with the SDK which wants to change the filesystem layout and add a prefix Sep 11 14:34:51 If you don't change layout_bindir it breaks since it puts the bins in the wrong place. If you do change it, it also breaks as PATH is corrupted Sep 11 14:36:05 We have possibly four different layouts for the filesystems - "native", "cross", "target" and "sdk" Sep 11 14:36:26 currently native == target and cross is just special Sep 11 14:38:41 th1_: I can't think of any system-wide thing that would be likely to stop cut and paste working altogether, unless you have some rogue clipboard manager running. Sep 11 14:38:53 Does this happen if you just have xterm and nothing else in the session? Sep 11 14:40:00 pb__, it happens when I have only xterm, xfce4-mcs-panel, xfwm4, notification-daemon, and xterm Sep 11 14:40:31 on my desktop when I try to run xclipboard it complains that a clipboard manager is already running, that doesn't happen on the OE box so I'm guessing no to rogue clipboard managers.. Sep 11 14:43:11 hm. well, that is very weird. Sep 11 14:43:32 unfortunately I don't think there is any convenient tool to find out who owns a particular selection. you'd think that xdpyinfo might be able to do it but it seems not. Sep 11 14:48:24 yep, it's damn weird ;) Sep 11 14:48:24 khem|away: looks like cherokee-admin requires python ... Sep 11 15:04:32 g'day kergoth Sep 11 15:04:53 th1_: you could try to reproduce the problem in xnest on your desktop, that might give some clues as to the cause. Sep 11 15:05:15 hi kergoth Sep 11 15:05:29 hi kergoth Sep 11 15:06:41 hey Sep 11 15:25:12 pb__, I can reproduce it on my OE box with ONLY X and Xterm running at least now Sep 11 15:25:29 so it's nothing to do with xfce4 and friends Sep 11 15:27:48 righto, that's good progress Sep 11 15:28:00 how about if you run xterm from the OE box with $DISPLAY set to your desktop, or vice versa? Sep 11 15:28:17 that'd tell you whether the problem is in the client or the server. Sep 11 15:45:53 kergoth: Have you given these $layout_ variables any thought? Sep 11 15:46:50 not recently, been busy this sprint implementing other features for work Sep 11 15:47:27 kergoth: I'm coming down in favour of ripping them out (I was the person who introduced them too :/ ) Sep 11 15:49:59 well, either staging could reflect the target layout without harm, or apps that use sysroot require a specific layout in staging. if the latter, i can see the use of layout_*, but perhaps it should be made more clear that the user shouldn't ever override them, nor should recipes ever use them.. Sep 11 15:50:14 * kergoth shrugs, would need to give it more thought, with more caffeine in his system, probably ;) Sep 11 15:52:44 RP: opinion on changing emit_var to run str() on the value rather than aborting if it isn't a string? Sep 11 15:54:26 NOTE: TEST_TYPECHECK_LIST2 (type list) = '/usr/local/bin:/usr/bin:/bin' (['/usr/local/bin', '/usr/bin', '/bin']) Sep 11 15:54:26 NOTE: TEST_TYPECHECK_BOOL_SUCCEED2 (type boolean) = 'False' (False) Sep 11 15:54:26 NOTE: TEST_TYPECHECK_LIST (type list) = 'alpha beta theta' (['alpha', 'beta', 'theta']) Sep 11 15:54:27 ERROR: TEST_TYPECHECK_BOOL_FAIL: 'somevalue' is not a valid value for type boolean. Sep 11 15:54:35 heh, experimenting with a type checker for config vars Sep 11 15:54:55 (not for work, i just threw together a proof of concept cause i was bored) Sep 11 15:55:03 kergoth: I'm not keen - it will start dumping python functions and things? Sep 11 15:56:31 hmm Sep 11 15:56:33 * kergoth double checks the code Sep 11 15:56:57 RP: it already doesn't emit stuff flagged as 'python' Sep 11 15:57:06 RP: but there's also a "if type(val) is not types.StringType" Sep 11 15:57:09 which should die in a fire Sep 11 15:57:30 if we *really* want that check, which i don't think we do, as it's not pythonic, it should use if not isinstance(val, basestring): Sep 11 15:59:30 kergoth: There is/was other binary stuff in the dict such as the diagraph Sep 11 15:59:39 kergoth: In a way I'd prefer adding a new function Sep 11 15:59:55 No harm in making the type checks pythonic though, thats just our ignorance Sep 11 15:59:58 then we should make it ignore "__" prefixed variables Sep 11 16:00:50 * kergoth shrugs, just an idea Sep 11 16:00:58 kergoth: Are you after to use the output from bitbake -e ? Sep 11 16:01:16 kergoth: or just use the function for something evil? :) Sep 11 16:02:08 -e mostly. i'm thinking about python objects in the datastore that know how to convert themselves into useful string values. Sep 11 16:02:12 with __str__ methods Sep 11 16:02:28 kergoth: Its certainly worth considering Sep 11 16:02:36 kergoth: Perhaps do it for trunk but not 1.8? Sep 11 16:02:40 could always just emit them if run with 'all', for -e, but not for shell functions Sep 11 16:02:42 * kergoth nods Sep 11 16:03:23 this type checker i threw together doesn't just check the types, it replaces the strings with python objects that know how to check themselves in the constructor, and act like sane python objects, and can convert to sane strings Sep 11 16:03:24 check this Sep 11 16:03:42 TESTVAR[type] = "list" TESTVAR = "/usr/local/bin:/usr/bin:/bin" TESTVAR[separator] = ":" Sep 11 16:04:00 I sent email the dev list about the layout_ stuff explaining my problem and proposed solution... Sep 11 16:04:03 d.getVar("TESTVAR", ..) -> gives you a python list, iterating over it gives you /usr/local/bin, then /usr/bin, then /bin Sep 11 16:04:12 but if you str() on it, it gives you back "/usr/local/bin:/usr/bin:/bin" Sep 11 16:04:34 kergoth: That is cool and could clean up some of the code even internal to bitbake... Sep 11 16:04:48 although at a cost of speed :/ Sep 11 16:04:50 course, i can work around that need by making it a string that has a different __iter__ also, as a different implementation Sep 11 16:05:04 well, the conversions / checks would happen at finalize time Sep 11 16:05:10 shouldn't be too terrible a cost, i wouldn't think Sep 11 16:05:17 well, actually, config parsed time Sep 11 16:05:30 anyway,something to give thought to Sep 11 16:05:37 yes, its a neat idea Sep 11 16:05:58 Its the cost of the "is TESTVAR a list" check that could kill us Sep 11 16:06:28 but if it's only done for config variables, it will only happen once Sep 11 16:06:33 i doubt it would be statistically significant Sep 11 16:06:38 and, i'm using flags to control the checking Sep 11 16:06:41 it's not checking everything Sep 11 16:06:46 here's the prototype: http://gist.github.com/185387 Sep 11 16:06:54 I'm thinking bigger than config variables Sep 11 16:06:58 bbl Sep 11 16:07:04 oh, you're thinking about adding support directly to bitbake for it.. i still think flags might be the way to go Sep 11 16:07:09 directly declare what it is Sep 11 16:07:56 kergoth: right, agreed. but then you have to check the flag Sep 11 16:07:56 the prototype is dead simple, would be really easy to add it to OE, or something like it Sep 11 16:08:04 and checking flags is costly :/ Sep 11 16:08:20 (in the parser) Sep 11 16:08:31 i'm really starting to regret the way we designed this thing Sep 11 16:08:42 yes, everything as metadata and using flags is cute, but.. Sep 11 16:09:20 for half of what we do in OE you have to know python anyway, in which case it could be done as python modules instead of cramming it into metadata Sep 11 16:09:23 * kergoth grumbles Sep 11 16:10:16 kergoth: That would change if we added another language for functions :) Sep 11 16:10:46 could always switch to .NET/Mono, then you could write your assemblies in your .net language of choice ;) Sep 11 16:10:50 Support for FORTRAN in there would be great... Sep 11 16:11:12 kergoth: :) Sep 11 16:11:17 getting bitbake to run under ironpython is on my list Sep 11 16:11:18 hehe Sep 11 16:13:13 anyway, the type checking stuff might be worth adding to OE, if not bitbake Sep 11 16:13:21 right now there's a lot of inconsistency in the semantics of our configuration variables Sep 11 16:13:26 kergoth: yes Sep 11 16:14:54 Hmm, this mess my build has turned into is the kind of thing nervous breakdowns are made of... Sep 11 16:15:12 :( Sep 11 16:18:47 * kergoth mulls over the behavior of the bitbake verbosity/debugging/logging commandline options and a potential switch to the python logging module Sep 11 16:19:27 kergoth: Trying to change the layout variables and a create new set of toolchain recipes at the same time all using CLASSEXTEND may not have been a great idea... Sep 11 16:19:48 yikes Sep 11 16:20:21 that's why i keep separate projects for each task. where the project is a build directory that has its own working copies of the collections, and occasionally, a git-new-workdir of the bitbake git repo Sep 11 16:22:14 kergoth: I started on A which required B to change which reqired C :/ Sep 11 16:22:19 ugh Sep 11 16:22:21 i hate those Sep 11 16:24:15 for those, i find its best to -try- to complete each one first, or at least get them committed to avoid mixing them up in the working copy.. but even then... when one can break the others, pain in the ass Sep 11 16:24:17 good luck :) Sep 11 16:31:28 kergoth: Makes sense, I'm just trying to disentangle them :) Sep 11 16:31:53 and now I discover a limitation of gcc sysroot :/ Sep 11 16:43:00 only downside to so many projects... i have half written prototypes and proofs of concept laying all over the place, and i don't remember which ones got pushed and which haven't :) Sep 11 16:43:11 hrmph Sep 11 16:53:49 RP: has poky run into any problems with --as-needed yet? I'm sure some apps will break with it do to doing bad things, and i'm sure not all buildsystems will add it -preceding- the libs being linked, rather than after.. Sep 11 16:53:59 i want to enable it for mvl6, but we have to be very careful Sep 11 16:54:02 :) Sep 11 16:54:15 kergoth: Its enabled in poky and we have a small backlist Sep 11 16:54:33 but I'm sure its not being positioned correctly on some compiler commandlines Sep 11 16:54:49 hmm, okay, thatd be a good starting point. maybe i can get QA to help me re-test everything with the change but without committing it to master yet Sep 11 16:54:52 * kergoth nods Sep 11 16:54:53 The solution is moblin's binutils patch which I keep meaming to add Sep 11 16:55:00 03Khem Raj  07org.openembedded.dev * r48e831f5be 10openembedded.git/recipes/binutils/binutils_cvs.bb: Sep 11 16:55:00 binutils_cvs.bb: Do not use autotools_do_install Sep 11 16:55:00 * CVS checkout include full src tree so we can not Sep 11 16:55:00 do make install because then it will try to install Sep 11 16:55:00 every component in src. We have to install ld Sep 11 16:55:02 gas and binutils only. Sep 11 16:55:06 Signed-off-by: Khem Raj Sep 11 16:55:10 03Khem Raj  07org.openembedded.dev * r7e1ca09587 10openembedded.git/recipes/ (lsof/lsof_4.78.bb tcp-wrappers/tcp-wrappers_7.6.bb): Sep 11 16:55:11 lsof, tcp-wrappers: Fix compilation on linux-uclibceabi Sep 11 16:55:13 Signed-off-by: Khem Raj Sep 11 17:03:06 RP: is this moblin binutils patch online anywhere? :) Sep 11 17:13:56 does anyone know of a package that will provide resize2fs ? Sep 11 17:13:59 or do I have to use parted? Sep 11 17:14:06 and e2fsprogs-libs Sep 11 17:14:13 (i grepped for it) Sep 11 17:14:17 kergoth: Its in the moblin bintuils source rpm Sep 11 17:14:36 kergoth: I'll find it later if you can't but I need to run away now ;-) Sep 11 17:14:50 * RP -> pub Sep 11 17:15:17 hehe, np Sep 11 17:15:26 jconnolly its in e2fsprogs Sep 11 17:18:07 m4t: is it? PACKAGES =+ "e2fsprogs-blkid e2fsprogs-uuidgen e2fsprogs-e2fsck e2fsprogs-mke2fs e2fsprogs-fsck e2fsprogs-tune2fs e2fsprogs-badblocks" Sep 11 17:18:21 no resize2fs though Sep 11 17:18:29 that's 1.41.5 Sep 11 17:18:32 then its probably in e2fsprogs, not a separate binary package. Sep 11 17:18:34 note the =+ Sep 11 17:18:39 it isn't removing the default packages Sep 11 17:18:44 only adding more specific ones Sep 11 17:18:57 try installing the "e2fsprogs" ipk Sep 11 17:18:58 gotcha Sep 11 17:19:39 yes you're right kergoth Sep 11 17:19:41 thx Sep 11 17:19:43 np Sep 11 17:45:45 i've been bumping package versions that im using to the latest available, going from a->z Sep 11 17:45:59 and i ran into a problem with 'g' (gnupg 1.4.10/svn): Sep 11 17:46:09 http://pastebin.com/m6b7d7440 shows the build error Sep 11 17:46:48 i couldnt find any major differences in the makesfiles between versions Sep 11 17:49:15 btw: resize2fs 1.41.9 (22-Aug-2009) Sep 11 17:49:20 that one was easy ;/ Sep 11 18:07:58 re Sep 11 18:10:19 kergoth still there? Sep 11 18:12:13 yep Sep 11 18:12:14 whats up Sep 11 18:14:20 I want to fix console-image building Sep 11 18:14:25 with the bluez4 stuff Sep 11 18:14:33 so not that X is not compiled Sep 11 18:14:42 pb mentioned you looked at it too Sep 11 18:24:36 woglinde: divide bluez into apps and libs recipes Sep 11 18:25:29 woglinde: then the packages which need libs will not have deps on apps and inturn will avoid pulling in x Sep 11 18:31:14 yeah, exactly. pb did a first pass split, we're using that with some tweaks for mvl6 Sep 11 18:34:13 kergoth: are you going to OEDEM? Sep 11 18:36:53 kergoth hm can you provide me your work? Sep 11 18:37:20 khem yes http://patchwork.openembedded.org/patch/651/ Sep 11 18:42:18 denix: sadly, no, can't afford to. will have to budget for the flight for next year Sep 11 18:42:31 * kergoth 's landlord just told him he has 30 days to find another place, as he's likely selling this one Sep 11 18:42:55 kergoth: convince him that market is not good yet :) Sep 11 18:42:56 kergoth :( Sep 11 18:42:57 kergoth: bummer, for both of those Sep 11 18:43:07 he is better off renting it to you Sep 11 18:43:21 kergoth: is it a SFR ? Sep 11 18:43:52 just renting a house from a private homeowner. we already found a place, thankfully... now to finish packing in the next... 8 days.. Sep 11 18:44:02 * kergoth sighs, moving sucks Sep 11 18:44:12 kergoth: you have one day less than me I have 9 days :) Sep 11 18:44:19 * khem nods Sep 11 18:44:58 may need to take a couple days off next week to finish up Sep 11 18:44:59 heh Sep 11 18:45:01 fun fun Sep 11 18:45:03 why are you moving? Sep 11 18:46:47 I bought a home Sep 11 18:46:52 oh, nice, grats :) Sep 11 18:47:01 good time to buy, i'm sure Sep 11 18:47:11 khem hehe Sep 11 18:47:23 yes but you need a good agent ? mine was a sucker Sep 11 18:47:41 he did not negotiate hard enough Sep 11 18:49:31 ahh Sep 11 18:50:00 03Martin Jansa  07shr/import * r6ffd9fa17b 10openembedded.git/ (3 files in 2 dirs): Intone-video bbfiles Sep 11 18:50:02 03Thomas Zimmermann  07shr/import * r2e07a072e2 10openembedded.git/recipes/python/ (6 files in 2 dirs): Add reciepes for pisi depencies Sep 11 18:50:04 03Thomas Zimmermann  07shr/import * r703faa469c 10openembedded.git/ (2 files in 2 dirs): Add pisi reciepe Sep 11 18:50:05 03Martin Jansa  07shr/import * re1e72a850e 10openembedded.git/recipes/intone/intone_svn.bb: Intone: Add missing jpg, remove glade, docs in /usr/share/doc/ Sep 11 18:50:20 huh, converting bb.msg to use the logging module, and not firing the msg events (the gui should be able to use a logging handler instead) reduces the parse time of the mvl6 collections by 1.13 seconds (originally 14.6, now 13.47) Sep 11 18:50:47 thats like 20% Sep 11 18:50:51 nice Sep 11 18:51:48 i should test with upstream OE, that's the big one Sep 11 18:51:50 * kergoth tests Sep 11 18:52:37 the speed up was definitely noticable, or i woudlnt have taken the time to measure it :) Sep 11 18:53:37 is it on top of 1.8 Sep 11 18:53:57 for now, will have to make more changes for master, due to the way the guis do the messaging Sep 11 18:54:21 i'll port it to master when i see about pushing it upstream.. shouldn't be too long, i'll move it up to the top of my queue Sep 11 18:54:48 was surprisingly easy to implement. i do think we should think about changing the semantics of our commandline arguments for it though Sep 11 18:55:39 I think -v should be the one that adjusts level, and -D should just allow display of debug messages. so -vvv -D instead of -DDD. right now the behavior of -v isn't exactly obvious or intuitive to people Sep 11 18:56:11 then you could do -vvv -l Parsing -l TaskData instead of -l Parsing -l Parsing -l Parsing -l TaskData -l TaskData -l TaskData ;) Sep 11 18:58:26 why so much repeats Sep 11 18:58:43 each instance bumps the log/debug level for that domain Sep 11 18:58:53 -l Parsing -l Parsing is like -DD, but only for parsing messages Sep 11 18:59:00 each -l bumps it by one Sep 11 18:59:18 it's very useful to avoid -D, since -DDD is just too damn much Sep 11 18:59:23 too much output to make sense of Sep 11 18:59:35 -vvv Parsing should be equal to three of them would be nice Sep 11 18:59:45 yeah, i think i'll add it to my list for master Sep 11 18:59:49 not 1.8, since it changes behavior Sep 11 19:00:17 kergoth: doh, evicted? how annoying. Sep 11 19:00:49 yeah.. nothing our fault, just our 12 month lease ran out and he decided to let us stay one month, then give us the boot for his own reasons Sep 11 19:01:00 30 day notice to move when you both work full time is rather annoying Sep 11 19:01:44 yeah, sounds like a nuisance. oh well. Sep 11 19:01:53 aye Sep 11 19:02:35 khem: I think it should be fine to switch micro to gcc 4.4.1, but woglinde wants to do something with the kernel headers first. Sep 11 19:02:59 so, once his patch is in, I will change the gcc version. Sep 11 19:03:58 switch to logging only saves about 4.4 seconds on a full bitbake parse (126.37 -> 122.77 seconds) Sep 11 19:04:03 we could possibly do with a newer binutils too, 2.18 is pretty old and I am not sure how well it deals with all the thumb bits. Sep 11 19:04:14 still, given performance wasn't the intended point of it, joy Sep 11 19:04:36 kergoth: sounds good. Sep 11 19:04:45 a bit surprising, but good :-} Sep 11 19:05:04 it was firing bitbake events (bb.event) for every message printed Sep 11 19:05:09 not pleasant, i think it was for the ui split Sep 11 19:05:17 oh right. Sep 11 19:05:31 which means it ran the in metadata event handlers for all of those.. though they immediately exited, that could be noticable Sep 11 19:05:37 heh Sep 11 19:05:56 anyway, figured with this done we can think about adding the ability to emit actual log files rather than doing all this piping Sep 11 19:06:04 (for the build itself, that is) Sep 11 19:06:59 yes, that would be a bonus Sep 11 19:09:44 pb____: I bumped it already I thought you were ok once the visibility stuff was sorted out so I took your auto ack Sep 11 19:10:24 with newer kernels I was thinking that linux-libc-headers should be derived out of same sources the kernel is built from Sep 11 19:10:42 now the headers target is maintained well on lnx upstream Sep 11 19:11:38 this will also get rid of mismatches sometimes headers have syscalls wired but kernel that runs on the box does not etc. Sep 11 19:11:54 any pros cons one can think of unifying these Sep 11 19:16:16 oh, right. okay, woglinde will just have to cope with that as best he can. Sep 11 19:16:43 I don't think it should be much of a problem for him anyway. Sep 11 19:17:44 for linux-libc-headers, the mismatch shouldn't be an issue: libc has always been responsible for providing the appropriate fallbacks, and the presence of a __NR_thing has never been a guarantee that the syscall is actually going to work at runtime. Sep 11 19:18:03 I'm not really au fait enough with the way the kernel is maintained upstream to say whether we should be using their headers, unmolested, or not. Sep 11 19:18:52 last I heard, the stated position of the kernel h4x0rs was that their headers were basically just for them, and any userspace l4m3rz should maintain their own (hence linux-libc-headers). if that's changed, I guess that's fine. Sep 11 19:22:19 pb____: with david woodhouse's efforts its in there now Sep 11 19:22:34 and they take good care of maintaining the userspace interfaces Sep 11 19:23:04 crumbs, I wonder how that happened. did they all get a bang on the head or something? Sep 11 19:23:32 next they'll be proposing to not break the kernel module abi with every release. Sep 11 19:24:56 oh well. if that's true, and if it actually works (which I guess means, if other mainstream distros are using those headers) then there's probably no reason for us not to do that. Sep 11 19:25:16 we could always switch back again if the kernel dudes have any kind of relapse. Sep 11 19:28:05 re Sep 11 19:28:53 binutils 2.18 and 2.19.x is no good for thumb Sep 11 19:29:15 I am relying on cvs recipe as of now and waiting for 2.20 release Sep 11 19:30:16 hm Sep 11 19:30:25 pb I think you can bump anyway Sep 11 19:30:39 I thought the udev problem was fixed with newer headers Sep 11 19:31:07 so we can wait until the ppoll patch is in the kernel Sep 11 19:31:22 and use older udev Sep 11 19:31:25 or mdev Sep 11 19:31:26 *g* Sep 11 19:31:51 hm Sep 11 19:32:07 for bluez4 a good compromize is maybee Sep 11 19:32:22 to have bluez-utils bluez-apps-base and bluez-apps Sep 11 19:32:50 woglinde: yeah ppoll and pselect are not wired for arm in kernel yet Sep 11 19:32:55 the patch is floating around Sep 11 19:33:08 khem jepp I learned that Sep 11 19:33:15 bluez-apps-base could contain the apps for console-image Sep 11 19:33:29 and the rest like gst and cups could got to bluez-apps Sep 11 19:33:54 I think you should put essentially all the apps in their own packages. They're all basically independent. Sep 11 19:34:22 pb hm but they can be build with one recipe Sep 11 19:34:43 and than why some changed the .bb for bluez4 Sep 11 19:35:09 if you have them built with one recipe, you basically have the same dependency hell all over again. Sep 11 19:35:22 things with big dependency stacks, notably gstreamer and cups, really ought to be in their own recipes Sep 11 19:35:34 pb thats why I said make two recipes for apps Sep 11 19:35:36 one basic Sep 11 19:35:42 one with the leftout Sep 11 19:36:05 hm Sep 11 19:36:06 right, but that doesn't solve the problem. Sep 11 19:36:17 which problem? Sep 11 19:36:19 if you just have one with "the leftout", then you still end up building gstreamer if all you wanted was the cups plugin Sep 11 19:36:23 or vice versa Sep 11 19:36:29 hms Sep 11 19:37:12 but, just splitting the apps from the libs would be a start. Sep 11 19:38:16 hi jay7 Sep 11 19:38:54 woglinde: morning :) Sep 11 19:42:03 03Phil Blundell  07org.openembedded.dev * rb1213a3ec4 10openembedded.git/conf/distro/micro.conf: micro: select binutils 2.19.51 Sep 11 19:44:29 I see ABI change in my TMPDIR all of a sudden after my latest git pull :-/ Sep 11 19:45:24 khem hm I faced a problem now with uclibc Sep 11 19:45:44 The directory that should contain system headers does not exist: Sep 11 19:45:51 gcc intermediate Sep 11 19:56:12 woglinde: which version of uclibc ? Sep 11 19:56:28 0.9.30.1 Sep 11 19:56:53 yes Sep 11 19:57:11 rkirti: yes few naming convention changed you have to do a complete build from scratch Sep 11 19:57:24 if ! $(inhibit_libc) && test ! -d ${SYSTEM_HEADER_DIR}; then \ echo The directory that should contain system headers does not exist: >&2 Sep 11 19:57:30 thats from gcc Makefile Sep 11 19:57:38 4.4.1 Sep 11 19:57:50 woglinde: hmm it seems the headers didnt get installed properly Sep 11 19:57:57 khem: thanks for the info. what/whose naming are we talking about ? Sep 11 19:58:23 compilers mainly Sep 11 19:59:32 ok, Sep 11 19:59:40 khem any idea? Sep 11 20:00:00 machine is qemuarm Sep 11 20:00:00 what happens in this case if I have packaged staging, will it still resort to that or build afresh ? Sep 11 20:00:08 woglinde: can you check in your staging area if uclibc headers are installed Sep 11 20:00:40 rkirti: you should delete your tmp and rebuild everything Sep 11 20:00:49 khem they are installed Sep 11 20:01:03 hm in micro we are using /include Sep 11 20:01:07 maybee this is the problem? Sep 11 20:01:18 woglinde: ok hmm that could be Sep 11 20:01:51 actually try to revert one of my patches to gcc 4.4.1 Sep 11 20:01:54 khem I thought you tested it *g* Sep 11 20:05:33 I did Sep 11 20:06:29 khem is there a change btw. gcc-4.3 and 4.4? Sep 11 20:07:03 on minimal Sep 11 20:07:30 give me sometime Sep 11 20:07:35 I think I know what the problem is Sep 11 20:07:46 we had target gcc broken before Sep 11 20:07:52 which I fixed Sep 11 20:07:58 and that caused this issue Sep 11 20:08:02 I think Sep 11 20:08:37 flattening the dir structure is more pain than the benifits Sep 11 20:10:22 hi bluelightning Sep 11 20:10:34 hi woglinde Sep 11 20:12:25 * khem needs a pool of machines to test toolchain changes Sep 11 20:19:31 hms ah Sep 11 20:19:44 yeah its searching under /devel/arm/oetmp-uclibc/staging/armv5te-oe-linux-uclibceabi/usr/include Sep 11 20:19:54 didnt look at the second line the makefile Sep 11 20:21:18 woglinde: pb____ why this flattening of tree for micro Sep 11 20:21:23 what are advantages Sep 11 20:21:40 I only see pain part of it Sep 11 20:22:13 khem -> http://pastebin.com/m4381e507 Sep 11 20:22:52 jo ant Sep 11 20:23:43 woglinde: hello Sep 11 20:24:33 hmm, now that bb.msg is converted to logging, should think about deprecating bb.msg entirely Sep 11 20:24:33 woglinde: I'll post an RFC for packaged-staging (sync with poky). It's broken since ages in OE... Sep 11 20:24:47 woglinde: I'll need two acks Sep 11 20:25:27 khem: faster loading and less disk space usage. Sep 11 20:25:30 kergoth do it Sep 11 20:25:33 * kergoth thinks... could probably do most of it with sed Sep 11 20:25:45 pb did you see my pastebin? Sep 11 20:25:52 no, which one was that? Sep 11 20:25:52 maybee we need to patch gcc-4.4 Sep 11 20:25:59 http://pastebin.com/m4381e507 Sep 11 20:26:14 woglinde: yes Sep 11 20:26:32 actually using exec_precfix/include is the right thingto do Sep 11 20:26:43 let me try it out here Sep 11 20:27:57 woglinde: ah, I see. yes, that needs patching. Sep 11 20:28:18 pb gcc is failing Sep 11 20:28:38 khem good that I tested Sep 11 20:29:47 pb____: but that breaks rest of distros the way it was patched before Sep 11 20:29:54 micro is unique Sep 11 20:31:20 micro probably is unique of the "standard" distros, but the hard-coded reference to /usr/include is just wrong in general. it's only right for minimal, say, by coincidence. Sep 11 20:31:22 this is what broke it http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=2aaa2e297f98a239a628706124615a7816a6b662 Sep 11 20:32:02 right, yes, undoing that gcc-configure-common.inc thing will definitely have broken it. Sep 11 20:32:07 that change was there for a reason :-} Sep 11 20:32:36 bad khem *g* Sep 11 20:33:00 pb____: this breaks target gcc Sep 11 20:33:09 that will probably have broken all gcc versions, incidentally, not just 4.4.1 Sep 11 20:33:17 so I think we need to fix it differently Sep 11 20:33:32 khem: in what way? that thing in gcc-configure-common has been there for months and nobody has complained previously. Sep 11 20:33:33 hm why this sed dont use -i Sep 11 20:33:35 yes gcc-configure-common.inc is pretty much everywhere Sep 11 20:33:37 03Martin Jansa  07shr/import * r2da61b33de 10openembedded.git/conf/checksums.ini: Missing checksum for vala-0.7.5-fso2.tar.gz Sep 11 20:33:38 03Martin Jansa  07shr/import * r0460f4b36c 10openembedded.git/conf/checksums.ini: Missing checksum webkit Sep 11 20:33:38 03Martin Jansa  07shr/import * r438793c192 10openembedded.git/conf/ (checksums.ini distro/include/sane-srcrevs.inc): Missing checksums for PISI dependencies Sep 11 20:33:47 03Martin Jansa  07shr/import * r556bcc7b19 10openembedded.git/conf/checksums.ini: Missing checksum ffalarms Sep 11 20:33:47 03Martin Jansa  07shr/import * rf0a867ce1d 10openembedded.git/conf/checksums.ini: Missing checksum midori Sep 11 20:33:58 possibly years even, I don't remember exactly when it was added but it was a while ago Sep 11 20:34:04 I will stick undo that change for now Sep 11 20:34:12 and think of micro when I fix it next time Sep 11 20:34:44 ah, october 2008. so, not quite a year, but still a fairly long time. Sep 11 20:35:10 if that was breaking all target gcc then I would have expected it to be a bigger issue by now. what was the problem you were having? Sep 11 20:35:26 woglinde: yeah sed -i is better Sep 11 20:35:40 hm better Sep 11 20:35:40 pb____: I think people just build cross-gcc Sep 11 20:35:44 it does the same Sep 11 20:35:46 but looks nicer Sep 11 20:36:03 pb____: particular problem is with gcc 4.4.1 Sep 11 20:36:16 I have not tried to build target gcc for other versions so cant saY Sep 11 20:36:24 woglinde: sed -i isn't standard, I think it's a gnu extension Sep 11 20:36:26 but I think it will break those too Sep 11 20:36:50 I guess there isn't really a policy on what versions of sed oe is meant to work with, but it doesn't seem terribly good form to use gnu specifics when there's no real need for them Sep 11 20:37:04 I agree Sep 11 20:37:10 anyone looked into opkg's behavior where it hangs when prompting during an install? it doesn't just assume the default value if stdin isn't a tty, the way it should Sep 11 20:37:15 * khem is trying to get oe building on mac lately Sep 11 20:37:23 pb okay Sep 11 20:37:28 kergoth: yeah, opkg is broken. no news there :-} Sep 11 20:37:30 but we use sed -i widely Sep 11 20:37:31 bah :) Sep 11 20:37:35 * kergoth has to fix it Sep 11 20:37:35 not problems until now Sep 11 20:38:01 khem: I guess the right thing to do with that bit of gcc-configure-common is just to conditionalise it on building gcc-cross rather than target gcc. Sep 11 20:38:25 sed has -i option on freebsd Sep 11 20:38:41 freebsd using gnu-sed? Sep 11 20:38:51 woglinde: no way Sep 11 20:39:23 but Sep 11 20:39:26 okay, i have a question. does anyone have an opinion on the bb.msg level handling? currently you can specify a level when calling debug(), do we want to retain that? In the logging module, severity (i.e. 'debug') *is* a debug level. I worked around it by adding new named levels next to debug, adjusted by the level, so it does work, I'm just wondering if we really need multiple levels of debug messages Sep 11 20:39:28 opinions? Sep 11 20:39:32 The -E, -I, -a and -i options, as well as the ``I'' flag to the address regular expression and substitution command are non-standard FreeBSD extensions and may not be available on other operating systems. Sep 11 20:39:38 I don't think solaris sed has -i, and it isn't in single unix either Sep 11 20:39:54 yeah Sep 11 20:40:14 kergoth: I don't think multiple debug levels are all that useful. being able to filter by module would be better. Sep 11 20:40:29 generally, either you're debugging or you aren't. Sep 11 20:40:55 pb__: sometimes its easy to look at less cluttered output Sep 11 20:41:09 so levels are a good way to control it I think Sep 11 20:41:41 well, i think often in that case you could use additional domains, or just not output those messages at all Sep 11 20:41:47 we need to audit our messages in general, many are completely useless Sep 11 20:41:50 yes, right. Sep 11 20:42:04 generally, if I am debugging a particular part of the code, I want to see all the messages from that module. Sep 11 20:42:16 yeah.. everyone i know either runs bitbake -DDD or no debugging at all Sep 11 20:42:18 okay then Sep 11 20:42:20 nothing worse than doing a debug run, then realising you hadn't enabled all output and having to run again Sep 11 20:42:41 conversely, if I'm not debugging that module, I don't want to see anything from it Sep 11 20:46:34 re florian Sep 11 20:50:23 any sed experts Sep 11 20:50:32 I want to remove last line of a file Sep 11 20:50:39 last non empty line Sep 11 20:50:48 use tail? Sep 11 20:51:00 tail -1 Sep 11 20:52:29 pb____: it'll be cool if we can leverage logging to, say, always emit the debugging info to a separate log file, so you don't have to re-run your builds with vs without Sep 11 20:52:31 heh Sep 11 20:55:14 cat gcc/defaults.h | grep -v "\#endif.*GCC_DEFAULTS_H" Sep 11 20:58:58 you know, keeping around multiple versions of the run/log scripts seems pretty useless to me Sep 11 20:59:06 has anyone ever had to go back and look at a previous one? Sep 11 20:59:14 judging by pid doesn't make that easy either Sep 11 21:02:31 kergoth: I have had horrid ways of getting my work done - I write 1-2 lines of shell script to do ls -l for all files, pick the one that matches the task I need, and most recent timestamp and return that filename Sep 11 21:02:41 hehe Sep 11 21:02:56 well, i'm thinking that maybe at some point we just make it overwrite the previous versions Sep 11 21:02:59 just have current Sep 11 21:03:17 i just don't see a real use case for the old Sep 11 21:03:46 pb____: lol about the userspace l4m3rz Sep 11 21:03:50 iirc, there was a request on uservoice to have a soft link with a constant name to point to the last logfile of the given task Sep 11 21:03:55 kergoth: ^^ Sep 11 21:03:58 rkirti: yeah, there is Sep 11 21:04:00 lalalaaallaa Sep 11 21:04:01 hmm Sep 11 21:04:07 well, its going on my list then.. Sep 11 21:05:05 pb____: khem enligthened me time ago: the kernel friends now provide sanitized headers Sep 11 21:06:29 hm the wine is good Sep 11 21:06:44 woglinde: mmm Sep 11 21:08:09 khem yes? Sep 11 21:08:19 woglinde: nm got it Sep 11 21:08:50 okay, definitely need to move subprocess/popen wrappers into a bitbake module Sep 11 21:09:12 woglinde: can you try this patch http://khem.pastey.net/125044 Sep 11 21:09:34 woglinde: rebuild gcc-cross-intermediate with it Sep 11 21:16:54 re Sep 11 21:17:23 http://bit.ly/OE_Tasks .. sad when 2 weeks of work is a tiny, tiny barely noticable bit of the list.. Sep 11 21:17:27 * kergoth shakes head Sep 11 21:18:55 guh, this is actually in bitbake: Sep 11 21:18:59 error("Function not specified") Sep 11 21:19:01 raise FuncFailed() Sep 11 21:19:04 * kergoth sighs Sep 11 21:19:48 khem hahahahaaaa Sep 11 21:19:50 configure.ac:26: error: Please use exactly Autoconf 2.59 instead of 2.61 Sep 11 21:21:39 hmmm Sep 11 21:23:03 woglinde: is this new Sep 11 21:23:13 why dont I see it Sep 11 21:23:24 hm let me try whith initial Sep 11 21:24:11 wb florian Sep 11 21:24:14 maybee it happens after build when you try to rebuild Sep 11 21:24:18 woglinde: with this patch the target gcc built fine now I am building cross-gcc-intermediate for arm/micro Sep 11 21:24:38 woglinde: oh did you bitbake -c clean gcc-cross-intermediate Sep 11 21:26:32 yes Sep 11 21:26:39 woglinde: that paste was bogus Sep 11 21:26:46 here is correct patch http://khem.pastey.net/125048 Sep 11 21:26:50 same with inital Sep 11 21:27:38 maybee its my fault Sep 11 21:27:42 I cut and paste Sep 11 21:27:51 rather than use patch Sep 11 21:29:10 hm patch is failing here Sep 11 21:29:45 khem try again Sep 11 21:30:43 khem is the remove of the extraline 9- Sep 11 21:33:18 woglinde: http://sakrah.homelinux.org/Public/diff Sep 11 21:33:53 woglinde: it works for me on micro as well as on target gcc for minimal shoots both problems Sep 11 21:34:38 i need to stop adding things to my oe task list faster than i'm removing them Sep 11 21:37:24 kergoth: heh or you will have buffer overrun Sep 11 21:37:50 hehe Sep 11 21:37:56 khem yes seems good Sep 11 21:41:43 woglinde: ok Sep 11 21:41:59 I bump it in with your ack :) Sep 11 21:43:22 guh, bitbake has a lot of racy operations Sep 11 21:43:28 lots of "if this file exists, do that" Sep 11 21:45:13 03Khem Raj  07org.openembedded.dev * rc0f653bc90 10openembedded.git/recipes/gcc/gcc-configure-common.inc: Sep 11 21:45:13 gcc-configure-common.inc: Muck with NATIVE_SYSTEM_HEADER_DIR Sep 11 21:45:13 * GCC's notion of standard includes being in /usr/include is Sep 11 21:45:13 not valid for micro distro which uses flattened layout Sep 11 21:45:13 Signed-off-by: Khem Raj Sep 11 21:45:17 Signed-off-by: Henning Heinold Sep 11 22:18:57 khem: Your last patch looks like a problem I was just looking into :) Sep 11 22:19:12 hehe Sep 11 22:21:33 RP: you cool with this stuff i'm working on? converted bb.msg to use the logging module, and am now killing bb.msg usage in favor of direct use of the loggers from logging Sep 11 22:22:13 kergoth: Have you looked at what trunk does? Sep 11 22:22:40 kergoth: I'm afraid I don't know pythons logging that well :/ Sep 11 22:22:43 i assume it's using the msg events to handle display of messages in the gui, but you can add a handler to the logger to do other things than dump to console Sep 11 22:23:49 also, using it instead of using events drops the overall parse time by around 10% w/ 1.8, since it doesn't have to run the handlers in the metadata Sep 11 22:23:55 i'll take a closer look at master Sep 11 22:24:10 kergoth: Right, we should be able to add a hook to xmlrpc them to the clients then Sep 11 22:24:56 kergoth: Hmm, you nuked the handler events? Sep 11 22:25:33 just made bb.msg not fire events. right now its just a wrapper around access to loggers Sep 11 22:26:25 It'll be the lack of events firing thats the speedup? Sep 11 22:26:47 most likely Sep 11 22:26:59 i haven't checked, but it's still emitting the same messages to stdout, so i don't know what else it would be Sep 11 22:27:08 and in trunk we switch to relying on the events Sep 11 22:27:51 * kergoth nods, will see about porting it to master, add a new handler that sends it to the ui Sep 11 22:28:26 * RP totally agrees the log level stuff needs overhaul Sep 11 22:28:31 the interface is pretty clean. at the top of a module, say bb.fetch.bzr, import logging, set logger = logging.getLogger("BitBake.Fetcher"), and then run logger.info(), logger.error(), logger.debug() Sep 11 22:28:44 it inherits the settings of the "BitBake" logger Sep 11 22:28:48 which is configured by the bitbake script Sep 11 22:31:39 kergoth: the bitbake script? Sep 11 22:31:55 bin/bitbake Sep 11 22:32:07 anyone tried to build the kinetic branch of qt yet? Sep 11 22:32:08 kergoth: ah, right Sep 11 22:32:23 right now i have lib/bb/cooker.py configuring the debug levels and all the way it did before, but bin/bitbake itself sets up where the messages go Sep 11 22:32:43 kergoth: sounds sane but I need to look at it :) Sep 11 22:33:15 (python logging) sane choice, go for it Sep 11 22:34:49 i'll post the patches on a branch when i finish it up Sep 11 22:36:25 khem, woglinde: Is there no way of better dealing with the headers location with gcc than all that sed magic? :/ Sep 11 22:38:10 RP hm look at the Makefile yourself Sep 11 22:38:26 woglinde: I have been :/ Sep 11 22:38:42 here is the relevant part Sep 11 22:38:44 http://pastebin.com/m4381e507 Sep 11 22:40:08 woglinde: Patch it to make NATIVE_SYSROOT_HEADER_DIR configurable? Sep 11 22:40:49 gah, and it still fails, no because I have a none standard lib locatiion Sep 11 22:41:03 florian: ping ? Sep 11 22:41:08 okay Sep 11 22:41:14 rkirti: pong Sep 11 22:41:14 I have to go to bed now Sep 11 22:41:16 good nite Sep 11 22:41:21 gn woglinde Sep 11 22:41:24 woglinde: enjoy Sep 11 22:41:26 Its the change to defaults.h I hadn't got too Sep 11 22:41:29 eh good night ;) Sep 11 22:41:36 woglinde: Thats the magic bit... Sep 11 22:41:37 florian hehe Sep 11 22:41:39 florian: how good/sane an idea is it to have the OE sources mirror as the ONLY source ? Sep 11 22:41:41 woglinde: 'night Sep 11 22:41:45 rp hm Sep 11 22:42:01 seems I need to look into defaults.h too Sep 11 22:42:13 but not now Sep 11 22:42:34 florian: I have some crappy recipes for pakcages which are as such obsolete in maemo5 but are needed for my stuff...I could hunt out some really remote server having it - but that would be unsafe later Sep 11 22:42:34 rkirti: we had some discussions about this already. it seems that its the only solution sometimes... Sep 11 22:42:44 florian: I see. Sep 11 22:42:51 * rkirti wasnt aware Sep 11 22:43:25 rkirti: if you like we can place more or less anything at linuxtogo.org now anyway Sep 11 22:43:39 florian: hildon-desktop python-loader is one example. My HD needs it, so does mer, but its a deprecated/non-functional package in upstream Sep 11 22:43:45 florian: ok Sep 11 22:44:17 * florian just had a good idea that needs to be sketched in software now Sep 11 22:44:32 * rkirti struggles to clean up the mess in a no-iconv-detect patch Sep 11 22:45:19 * rkirti thinks generic patches to stop running stuff in do_configure, like no-iconv-detect, checking for abstract sockets etc should be documented in the wiki Sep 11 22:45:41 florian: idea about ? Sep 11 22:47:26 yes additional documentation is always a good idea. some wiki page about how to handle some tricky things creating new bbs would be nice Sep 11 22:56:33 * rkirti sighs. After the abi update, gcc cross doesnt build :-( Sep 11 23:05:03 rkirti, be strong! Sep 11 23:06:20 god night Sep 11 23:08:58 morning Laibsch Sep 11 23:11:07 good night Sep 11 23:29:34 RP: I think we have options in gcc configure to set include dirs Sep 11 23:29:54 RP: but they are are convoluted in OE's build mechanism its hard to unwind Sep 11 23:47:34 hmm . . . did I miss an announcement. just got this after a pull: Sep 11 23:47:42 TMPDIR has changed ABI (2 to 3) Sep 11 23:56:11 good night Sep 12 02:03:24 03Khem Raj  07org.openembedded.dev * raa6a11a716 10openembedded.git/recipes/screen/ (6 files in 2 dirs): Sep 12 02:03:24 screen-4.0.3: Fix compilation and make default. Sep 12 02:03:24 * Fix compilation issues. Sep 12 02:03:24 * Remove DEFAULT_PREFERENCE = "-1" Sep 12 02:03:24 * Tested on Thumb/uclibc Sep 12 02:03:25 Signed-off-by: Khem Raj **** ENDING LOGGING AT Sat Sep 12 02:59:56 2009