**** BEGIN LOGGING AT Thu Jun 16 02:59:57 2011 Jun 16 05:45:13 Does anyone know how default recipe is chosen as "git" when configuration doesn't specify PREFERRED_VERSION for a package? Jun 16 08:01:02 03Andreas Müller  07master * re0d8eb830a 10openembedded.git/conf/machine/mx28evk.conf: Jun 16 08:01:02 mx28evk: set valid console Jun 16 08:01:02 The initial patch was build tested only because hardware for tests was not Jun 16 08:01:02 available. Christian Borutta reported the following log: Jun 16 08:01:02 INIT: Id "S" respawning too fast: disabled for 5 minutes Jun 16 08:01:03 Signed-off-by: Andreas Mueller Jun 16 08:01:03 Signed-off-by: Eric Bénard Jun 16 08:01:13 03Andreas Müller  07master * r0de87683a6 10openembedded.git/conf/machine/include/imx28.inc: (log message trimmed) Jun 16 08:01:13 mx28 SOC: set correct addresses for u-boot Jun 16 08:01:13 The initial patch was build tested only because a hardware for tests was not Jun 16 08:01:13 available at the time initial patches were sent. The modifications lead to the Jun 16 08:01:13 following boot log (thanks to Christian Borutta for testing): Jun 16 08:01:13 U-Boot 2009.08 (May 09 2011 - 16:42:53) Jun 16 08:01:14 Freescale i.MX28 family Jun 16 08:07:24 morning all Jun 16 08:32:14 good morning bluelightning Jun 16 08:32:24 hi mgundes Jun 16 08:32:51 sorry, I have question again :) Jun 16 08:33:04 I want to install some cli tools to my image Jun 16 08:33:35 I added tasks-cli-tools to IMAGE_INSTALL variable in my image bb Jun 16 08:34:13 there are not many tools in this task file but too many packages were downloaded and compiled Jun 16 08:34:16 why is that? Jun 16 08:34:38 /home/kays/Perforce/10.1.10.20_1666/dev/argela/firmware/oe/openembedded/recipes/xorg-lib/libxrender_0.9.5.bb, do_compile) Jun 16 08:34:51 I dont have any package related to xorg Jun 16 08:35:23 why that kind of packages were compiled? Jun 16 08:36:18 NOTE: Running task 1283 of 2807 (ID: 2280, /home/kays/Perforce/10.1.10.20_1666/dev/argela/firmware/oe/openembedded/recipes/gstreamer/gstreamer_0.10.28.bb, do_patch) Jun 16 08:36:49 how can it compile gstreamer for cli tools :) Jun 16 08:40:42 by the way my machine features are: Jun 16 08:40:44 machine/pc7302.conf:18:MACHINE_FEATURES = " kernel26 uboot jffs2 serial " Jun 16 08:40:44 machine/pc7302.conf:19:MACHINE_EXTRA_RRECOMMENDS += " kernel-modules " Jun 16 08:49:58 mgundes: there's a difference between build time dependencies (DEPENDS) and runtime dependencies/recommendations (RDEPENDS / RRECOMMENDS) Jun 16 08:50:43 mgundes: often recipes have build time dependencies that don't show up as runtime dependencies because they get split into different packages Jun 16 08:51:06 or rather, they do show up but only for one or two of the output packages for the recipe Jun 16 08:51:12 e.g. a plugin Jun 16 08:52:09 so this means you'll often see stuff getting built that doesn't end up in the final image Jun 16 08:55:51 iirc the chain was pcmcia feat. -> bluez -> gstreamer Jun 16 08:56:15 now, he only has uboot and serial, c'mon ... Jun 16 08:57:08 seems oe-core does manage features much better Jun 16 08:58:57 however it does not add rootfs image, it takes too long Jun 16 09:02:09 mgundes: fwiw there were some serial BT adapters around 10 yrs ago... Jun 16 09:04:53 actually I create a new file named task-cli-tools-mine.bb Jun 16 09:05:01 deleted unnecessary for me Jun 16 09:05:28 RDEPENDS_${PN} = "\ Jun 16 09:05:28 lsof \ Jun 16 09:05:28 nano \ Jun 16 09:05:28 " Jun 16 09:05:28 RDEPENDS_${PN}-debug = "\ Jun 16 09:05:29 that's best way probably Jun 16 09:05:29 ltrace \ Jun 16 09:05:31 strace \ Jun 16 09:05:33 tcpdump \ Jun 16 09:05:35 " Jun 16 09:05:59 but it still has too many tasks to be done Jun 16 09:07:30 I will untill finish and then check rootfs directory to see added application and libraries Jun 16 09:07:37 thanks Jun 16 09:16:58 oh, again ...initscript: Change some order of init scripts Jun 16 09:29:14 "Move udev script to execute ealier since module autoload needs it to Jun 16 09:29:16 hello Jun 16 09:29:17 create device nodes.".. imagine we changed this before because "udevadm called in udev init script loads all kernel modules in some unpredictable order" Jun 16 09:30:05 i had a builded a x11-image for mini2440 using oe... but I m getting wrong touch screen calibration....can anyone help me.... Jun 16 09:35:48 sanket: which X server? Jun 16 09:37:52 ant_work, sorry i didn't get you.... i had builded filesystem using oe for mini2440 (bitbake x11-image)..... image is working fine... but touchscreen is not working properly.... Jun 16 09:39:50 also there is nothing in xorg.conf..... it uses system config directory "/usr/share/X11/xorg.conf.d" ...... Jun 16 09:42:46 mini2440.conf doesn't set any XSERVER so it depends on distro or defaults Jun 16 09:44:17 ..or in x11-image: XSERVER ?= "xserver-kdrive-fbdev" Jun 16 09:44:30 well, I have some bad news for you :p Jun 16 09:45:09 ant_work, touchscreen is working with wrong calibration.... and what bad news? Jun 16 09:45:20 cannot be recalibrated :/ Jun 16 09:45:47 ant_work, how the calibration then take place.... Jun 16 09:46:22 today's status: http://lists.linuxtogo.org/pipermail/zaurus-devel/2011-June/000555.html Jun 16 09:51:54 ant_work, do you have any solution to come out of these..... gpe-image is working fine.... then why not this? Jun 16 09:52:40 do you se the crosshair when calibratingfrom gpe? Jun 16 09:52:59 yes... Jun 16 09:53:08 * ant_work kicks logi***h kb Jun 16 09:53:09 at first time... Jun 16 09:53:21 try to recalibrate :) Jun 16 09:53:41 anyway, I tested x11 and x11-gpe images, not plain gpe Jun 16 09:54:03 still it doesnot read ... pointercal..... it gives me wrong calibration Jun 16 09:55:06 yes, even in opie the calibration values are not acccepted as valid input so you cannotexit from calibration Jun 16 09:55:21 and opie has no X Jun 16 09:55:49 ant_work, can i recompile evdev package ? Jun 16 09:56:17 heh, don't ask me I'm out of solution atm :) Jun 16 09:56:31 I'll wait for Stanislav suggestions Jun 16 09:57:12 but those wrong pointercal values are nasty... Jun 16 09:57:26 one more thing.... system is reading 10-evdev.conf Jun 16 10:01:27 Hi, anyone using hostapd? Jun 16 10:01:57 I have up/down rules on network interfaces, which set static routes Jun 16 10:02:15 on hostapd launch those are deteled Jun 16 10:02:29 Trying to figure out how to keep them Jun 16 11:04:11 pb_: klibc repackaging has been done. Now, about the RDEPENDS for the klibc-utils, if I totally remove those lines I then see the control file in the ipk does not DEPENDS on libklibc (1.5.23-r2). Did you mean to change them as RDEPENDS_thisutil = "libklibc" ? Jun 16 11:05:42 No, that shouldn't be necessary. I think we should figure out why that isn't being done automatically. Jun 16 11:06:11 Do you get any "couldn't find shared library provider" kind of warnings during the build? Jun 16 11:06:32 not that I remember Jun 16 11:06:50 not on screen Jun 16 11:08:35 actually I found smthg a bit strange: the klibc-utils binaries are reported as being "statically linked (shared libs), stripped" Jun 16 11:08:52 whereby the static-utils are just static, stripped Jun 16 11:11:10 that is a bit weird Jun 16 11:11:19 can you show me the output of readelf -a on one of the binaries from klibc-utils? Jun 16 11:12:01 no, sorry, I haven't any offhand here Jun 16 11:14:22 ah Jun 16 11:22:25 I'll do later @home, anyway, the same binary (the first iirc, cat maybe..) was 2,5kb shared and 12kb srtatic Jun 16 11:23:15 is just that 'statically linked (uses shared libs)' which I woul not expect for a shared lib Jun 16 11:23:44 (but hey, I already confesses my blurred know-how about soname and co. :) Jun 16 12:16:26 khem: around? I was at University :-) Jun 16 12:54:01 hmm, ant_work, you were right, the reason of huge tasks list was bluez-lib Jun 16 12:54:18 bluez-lib is dependency for libpcap Jun 16 12:54:30 I deleted this dependency in libpcap bb Jun 16 12:54:42 then got a small tasks list Jun 16 12:55:05 by the way, what if I want to compile statically Jun 16 12:55:46 I think I should add "-static" parameter to CFLAG of tcpdump, but from where? Jun 16 13:08:47 mickey|daddy: Gratulation zum Nachwuchs ! Jun 16 13:40:48 mgundes: -static is a linker option Jun 16 13:42:07 wow, this channel is dead compared to it's state 4 or 5 years ago :-) Jun 16 13:42:29 ? Jun 16 13:42:41 you're just here at the wrong moment Jun 16 13:43:13 maybe. It used to be populated during european work hours as well Jun 16 13:43:18 no, he's right, it used to be way busier than this Jun 16 13:43:23 ok Jun 16 13:43:48 maybe because the zaurus era has come to an end? Jun 16 13:44:24 maybe :-) Jun 16 13:44:37 (I worked on my own device, not on Zaurus) Jun 16 13:44:41 whe, in 2012 like Maya said? Jun 16 13:45:31 I guess that was in the days when überhackers mickey and zecke were actively working on oe Jun 16 13:45:38 could always check the old logs from ibot and see who was here then :-) Jun 16 13:45:50 ah, the german crew, yes Jun 16 13:48:14 pb_: yes, and marcin and I ... and you :-) Jun 16 13:49:02 hehe, even I came just here into this chat to gratulate mickey for his successful replication Jun 16 13:49:13 :-) Jun 16 13:49:13 schurig_: damn, you disappeared just before finishing that modular-configuration for handhelds ;) Jun 16 13:49:31 dup(mickey) :-) Jun 16 13:49:35 modular-configuration? I think you confuse me Jun 16 13:49:38 http://ibot.rikers.org/%23oe/20070616.html.gz Jun 16 13:49:40 "today in history" Jun 16 13:50:29 mickey, koen, ggilbert, Laibsch, ljp, ... Jun 16 13:50:36 * eFfeM_work feels the activity in #oe has decreased since yocto (and I feel also the # of commits in oe have gone down) Jun 16 13:50:46 ant_work: I disappeard as soon as monotone was used, and I didn't reappier after the switch to git because I didn't need bitbake again since then Jun 16 13:51:03 np, that's life Jun 16 13:53:27 I appeared just before the monotone->git switch Jun 16 13:53:34 so I didn't know all that Jun 16 13:53:42 eFfeM_work: I sort of agree. What I also noticed is that there're people basing work on OE and not OE-Core Jun 16 13:53:44 at the zaurus era I had a pma430 instead Jun 16 13:54:06 I'd say all started to fade years ago when RP went to o-hand Jun 16 13:54:11 eFfeM_work: I'd prefer if people have already moved to OE-Core Jun 16 13:54:33 well, there isn't any stable release of oe-core yet, so I guess it is reasonable for folks to still be using oe classic. Jun 16 13:54:37 otavio I feel that the way to work with oe-core is not too well explained Jun 16 13:54:47 and there is still a whole bunch of stuff missing in oe core compared to classic oe Jun 16 13:54:54 eFfeM_work: yes, it is confusing indeed Jun 16 13:54:55 indeed for the stuff missing Jun 16 13:55:00 that's why I'm still on oe classic Jun 16 13:55:06 also I lack space for both Jun 16 13:55:09 tavio: you see, you're oblige to have your git tree Jun 16 13:55:09 see my reply on the thread OpenEmbedded Core - Ready for extended users Jun 16 13:55:30 ant_work: for what? OE-Core? Jun 16 13:55:36 for layers Jun 16 13:55:38 (and also the one from Phil), unfortunately that has not been picked up Jun 16 13:55:41 ant_work: not really. you can just use the provided layers Jun 16 13:56:09 no, unfortunately no yet Jun 16 13:56:45 One thing I do believe it would help is if people started to use #oe here. Ofthenly we need to move to #yocto to get things discussed Jun 16 13:57:02 and it makes no-sense to me since oe-core is the basis of yocto Jun 16 13:57:29 sounds to me like the Debian / Ubuntu thingy Jun 16 13:57:31 much is discussed in poky/yocto ml Jun 16 13:57:37 schurig_: indeed Jun 16 13:57:59 why peoples happy with oe would move to oe-core / yocto ? There is a choice and not everyone has time to play with new toys everytime they come around ;-) Jun 16 13:58:00 too much lists and channels Jun 16 13:58:06 I have no more labels for Gmail, help Jun 16 13:58:16 one dump question: did anyone in those years make a bitbake-driven Android image builder? Jun 16 13:58:34 not that I'm aware of Jun 16 13:58:46 ericben: oe-core basis are good. The problem is that it lacks some basic stuff Jun 16 13:59:09 ericben: and people are focused on new releases instead of finishing bringing what we had on oe-dev Jun 16 13:59:19 which at the moment makes it less suitable if you have to deliver a product in a few months Jun 16 13:59:19 schurig_, yes that exist Jun 16 13:59:20 ericben: people at yocto (from my POV) Jun 16 13:59:32 GNUtoo: do you have any link? Jun 16 13:59:39 it was announced on the mailing list long time ago Jun 16 13:59:42 I've to look Jun 16 14:00:21 git://github.com/anguslees/openembedded-android.git Jun 16 14:00:45 otavio: I don't say the basis are not good, I just say that when you have products/services based on OE and are happy with that it's not easy to switch to a new thing in a short time especially when you are already fighting to find time in everyday's real life ;-) Jun 16 14:00:46 ericben: for example, I am fighting against cmake-nativesdk (one thing that works fine on oe-dev) Jun 16 14:00:51 the name of the thread is: Jun 16 14:00:53 "Initial work on an Android SDK via openembedded" Jun 16 14:01:34 Android is not easy to configure using it's own system so good luck to someone trying to split it into recipes Jun 16 14:01:48 hi GNUtoo btw Jun 16 14:01:52 hi Jun 16 14:02:15 GNUtoo: thanks Jun 16 14:03:25 schurig_, altough last commit seem to be from October 14, 2010 Jun 16 14:03:41 GNUtoo: yup, looks like a dead project Jun 16 14:03:55 maybe you could revive it? Jun 16 14:03:58 * eFfeM_work saw little encouragement to work on oe-core until now Jun 16 14:04:39 I just had this idea because I don't like the Android Update philosphy, that they don't have packages (ipk, deb, whatever). I thought making Android with bitbake would be a lot of work, but fun, and you get packages for free :-) Jun 16 14:05:15 however, I don't have a real use of it right now. Only android device in my house hold is an Archos 70, and that's the one of my wife, which I don't mess with :-) Jun 16 14:05:24 schurig_,it would be great to have more apps compatibility with that Jun 16 14:05:50 for instance with that we could do a mix of android and GNU/Linux applications Jun 16 14:06:02 for instance you bitbake the android SDL lib Jun 16 14:06:12 and then you build whatever game on top of that Jun 16 14:06:17 using bitbake Jun 16 14:06:39 that would also give a way to build the busybox and friends Jun 16 14:06:41 for android Jun 16 14:06:50 yep, exactly Jun 16 14:07:06 for the packages there are still apk+FDROID Jun 16 14:07:11 *Fdroid Jun 16 14:07:30 ( http://f-droid.org/repository/ ) Jun 16 14:09:56 the good thing about oe-core, though, is that most of the stuff it does have is of reasonable quality, whereas the recipes in oe classic tended to be a bit more hit and miss. Jun 16 14:10:13 that's not to say that oe-core is perfect in this respect, it has its share of junk too, but it's an improvement. Jun 16 14:10:18 specially old recipes Jun 16 14:10:49 for instance there are still recipes that use do_stage, and recipes that don't use INC_PR etc... Jun 16 14:11:06 I corrected some not so long ago Jun 16 14:12:44 davidlt, hi Jun 16 14:12:50 GNUtoo: hi Jun 16 14:13:01 pb_: I find the sysvinit/initscripts part particularly flaky in both oe-dev and oe-core Jun 16 14:13:01 I tested AP recently and it works fine Jun 16 14:13:10 on libertas_tf_sdio Jun 16 14:13:31 but I wonder if there is a public firmware that works now Jun 16 14:13:33 pb_: add module mgmt Jun 16 14:13:35 Yup, runs quite good, but still not perfect. Jun 16 14:13:55 because it can't be redistributed to customers, be included in oe etc... Jun 16 14:14:13 what's problematic beside PSM? Jun 16 14:14:14 I contacted cozybit company, so Steve doesn't work at their company anymore and they do not maintain this driver anymore. Jun 16 14:14:36 ok, so the driver is lost? Jun 16 14:14:50 We did more tested (a week ago) with WP7/Android/iPhone smartphones and laptops Jun 16 14:14:58 It still rebase easily on top of linux-next Jun 16 14:15:02 GNUtoo: I don't know, I can't contact Steve either, all contacts are lost Jun 16 14:15:19 maybe we should submit that upstream before it's lost for good Jun 16 14:15:31 So we have sometimes problems with AP, but it looks like more hostapd problems Jun 16 14:15:35 but there are no sign-off on the commits, right? Jun 16 14:15:59 Don't remember Jun 16 14:16:37 I think there was more patches for the driver (at least one), which is not included into Steve rep'o Jun 16 14:16:50 ah ok Jun 16 14:16:54 where are they? Jun 16 14:17:22 Steve has them, he mentioned them once Jun 16 14:17:31 ok Jun 16 14:17:42 where does he work now? Jun 16 14:17:55 I can't contact him, so I don't know much Jun 16 14:18:11 because if he does new commits somewhere Jun 16 14:18:20 there would be his mail appearing on the commits Jun 16 14:18:29 The driver hasn't been updated for a long time and all contacts are not working anymore Jun 16 14:20:06 I just need to reconfigure hostapd somehow to make it more stable. Jun 16 14:20:15 ok Jun 16 14:21:03 ant_work: I haven't noticed either of those things being too flaky for me, but I tend to use customised versions of the initscripts anyway. Jun 16 14:21:30 So far, disabling WMM and manually restarting hostapd fixes the problems. Jun 16 14:23:42 davidlt, he works at polycom now Jun 16 14:23:58 pb_: my /etc is overpopulated wrt modules Jun 16 14:24:02 ( http://www.linkedin.com/in/sdderosier ) Jun 16 14:24:02 Found any contacts? Jun 16 14:24:40 Ah, I think only premium users can send messages via linkedin? Jun 16 14:29:17 derosier gmail.com ? Jun 16 14:30:03 * davidlt quite dumb Jun 16 14:30:15 Gonna drop him a letter today Jun 16 14:30:22 ( http://groups.google.com/group/bbedit/tree/browse_frm/month/2010-03/34428a78e1dad641?rnum=11&_done=%2Fgroup%2Fbbedit%2Fbrowse_frm%2Fmonth%2F2010-03%3F ) Jun 16 14:30:37 ah mars 3 2010 Jun 16 14:30:49 altough he more likely kept that mail Jun 16 14:31:10 Btw, you have any ideas why restarting hostapd fixes most of stability problems? Jun 16 14:31:15 no Jun 16 14:31:42 I did some good and restarting hostapd looks like is the most common problem solver Jun 16 14:32:05 iPhone 3G works perfectly, 3GS doesn't want to connect (sometimes connects), Jun 16 14:32:24 WP7 tends to send multiple renew lease requests to dhcpd Jun 16 14:33:30 I had maybe two times when wireless access point completely vanished and restarting OS was required, that probably was drivers/firmware problems Jun 16 14:33:33 ok Jun 16 14:34:34 Sometimes you get similar messages: libertas_tf: PREP_CMD: command 0x001c failed: -110 Jun 16 14:34:44 ant_work: yes, -static is linker option, whatever, my aim is compiling any package statically Jun 16 14:34:53 how can I say that to bitbake? Jun 16 14:35:11 I haven't looked into that yet. At least with laptops it works perfectly, with smart phones I have some problems. Jun 16 14:35:24 mgundes: see helooworld Jun 16 14:35:46 RP__: are you there? Jun 16 14:35:56 in helloword it is compiled in do_compile() function Jun 16 14:36:06 RP__: I am in doubt how would be better to fix cmake issue with compilers I am having Jun 16 14:36:13 but in tcpdump bb, it uses default compile function Jun 16 14:36:27 -110 is timeout Jun 16 14:36:39 phones uses PSM Jun 16 14:38:45 And PSM stands for ? Jun 16 14:41:32 03Alexander Smirnov  07master * r814c44486d 10openembedded.git/recipes/wireshark/ (files/libtool-macroses-include.patch wireshark_1.2.6.bb): Jun 16 14:41:32 Set libtool to use correct lt-macroses Jun 16 14:41:32 Signed-off-by: Alexander Smirnov Jun 16 14:41:32 Signed-off-by: Dmitry Eremin-Solenikov Jun 16 14:41:43 03Alexander Smirnov  07master * r9fef5f074c 10openembedded.git/recipes/libnl/ (libnl1-1.1/fix-ucred-declaration.patch libnl1_1.1.bb): Jun 16 14:41:43 Add 'ucred' structure declaration in netlink headers for the integrity Jun 16 14:41:43 Signed-off-by: Alexander Smirnov Jun 16 14:41:43 Signed-off-by: Dmitry Eremin-Solenikov Jun 16 14:48:04 davidlt, power saving mode Jun 16 14:48:08 basically it works like that Jun 16 14:48:21 the AP buffers packets for the phone Jun 16 14:48:28 and the phone request them all at once Jun 16 14:48:32 and sleep in between Jun 16 14:48:40 iwconfig power on activate it Jun 16 14:50:31 Hmm, interesting, gonna do some reading Jun 16 14:51:05 there is a presentation about that on free elecrton but they have tons of presentations....so to find it .....you must spend quite some time Jun 16 14:51:19 so maybe linux-wireless is better Jun 16 14:54:04 http://www.linuxwireless.org/en/developers/Documentation/ieee80211/power-savings Jun 16 15:09:25 GNUtoo: I did some google regarding hostapd and PSM, looks like PSM might be supported by hostap Jun 16 15:10:17 Host AP mode doesn't support power saving. Clients attempting to use Jun 16 15:10:18 power saving mode may experience significant packet loss (disabling Jun 16 15:10:18 power saving on the client will fix this). Jun 16 15:12:26 strange Jun 16 15:12:32 because I've hostap on ath9k Jun 16 15:12:36 and it works fine Jun 16 15:13:41 But you have manually run iwconfig wlan0 power on to turn it on? Jun 16 15:14:50 that's to be done on target Jun 16 15:14:58 (phone) Jun 16 15:15:05 not on the AP Jun 16 15:15:28 try iwconfig wlan0 power on on laptops Jun 16 15:15:35 it will be a better test than phones Jun 16 15:15:46 since you have a full GNU/Linux on the laptop Jun 16 15:20:53 Hmm, so on AP side I don't have to do anything, while is client side option. I doubt that I can turn in on/off on WP7. Jun 16 15:24:01 indeed Jun 16 15:24:25 on AP side it may be an option of hostapd Jun 16 15:24:29 I don't really know Jun 16 15:24:44 but for sure you don't want/need to do iwconfig wlan0 power on on AP Jun 16 15:33:54 when I link my program, I get linking errors for libQtOpenGLE Jun 16 15:34:09 e.g.: sysroots/armv7a-none-linux-gnueabi/usr/lib/libQtOpenGLE.so: undefined reference to `QWSWindowSurface::directRegionId() const' Jun 16 15:34:09 ) Jun 16 15:34:15 and sysroots/armv7a-none-linux-gnueabi/usr/lib/libQtOpenGLE.so: undefined reference to `QEglContext::clearError()' Jun 16 15:35:21 QWSWindowSurface should be part of QtCore, and I link to it Jun 16 15:35:48 so I don't know why I get this error Jun 16 15:36:32 could there be a problem with libQtOpenGLE.so itself? Jun 16 16:52:45 hmmm on one of the boxes bitbake brings are system down to its knees Jun 16 16:52:57 its a quad core processor Jun 16 16:53:17 Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz Jun 16 16:53:35 and system freezes Jun 16 16:53:40 haha Jun 16 16:53:42 that's sad Jun 16 16:53:48 khem: yey :-) Jun 16 16:53:52 and its reproducable Jun 16 16:53:58 khem: do you have time for few questions? Jun 16 16:54:00 ible Jun 16 16:54:06 yeah sure Jun 16 16:54:16 * khem is really pissed off at bitbake Jun 16 16:54:37 cbrake: ever looked into making a version of oe-core (or otherwise reproduce the base recipes) entirely using srctree/gitver? Jun 16 16:54:44 same systems churns a fully blown toolchain in less than 10 minutes from scratch Jun 16 16:55:23 kergoth: any hints how to debug such a situation ? Jun 16 16:55:23 khem: well, I am working at getting cmake into shape for sdk Jun 16 16:55:25 kergoth: no, I never looked into it -- that would be interested though Jun 16 16:56:17 * khem has a meeting in 6 mins Jun 16 16:56:22 cbrake: i always liked the concept, figured it'd be nice, just have all the trees in sources/${PN} or something Jun 16 16:56:27 will have to play with it at some point Jun 16 16:56:35 khem: and it seems oe-core has changed a lot how it handled the compiler behind the schenes Jun 16 16:56:46 ideally using the upstream git repositories, but maybe with a branch to store bootstrapped bits (e.g. autotools generated bits) Jun 16 16:56:54 otavio: yeah Jun 16 16:56:57 khem: so nativesdk build of cmake fails completely basically because CC setting is made of compiler and flags Jun 16 16:57:09 khem: and cmake wants it to be compiler only Jun 16 16:57:15 kergoth: yes thats a nicer approarch I would say Jun 16 16:57:40 otavio: look into nativesdk.bbclass Jun 16 16:57:46 and see where its happening Jun 16 16:57:55 khem: I am at it and seems it is not there Jun 16 16:57:58 khem: not offhand, I'd start by twiddling with PARALLEL_MAKE/BB_NUMBER_THREADS. back it off and move it forward bit by bit, measuring the performance Jun 16 16:58:07 khem: but I guess it comes from more base class Jun 16 16:58:40 kergoth: Does that affect parsing and runqueue generation ?PARALLEL_MAKE/BB_NUMBER_THREADS that is Jun 16 16:59:00 kergoth: I would probably try to disable parallel parsing first Jun 16 16:59:06 is there a knob ? Jun 16 16:59:22 since when I kill bitbake python becomes zombie Jun 16 16:59:32 and I have to kill 2 python procs Jun 16 16:59:44 khem: hmm, no, but tehre is BB_NUMBER_PARSE_THREADS Jun 16 16:59:48 it defaults to based on the cpu_count() Jun 16 17:00:03 you could try BB_NUMBER_PARSE_THREADS = 1 just to see if it affects the behavior at all Jun 16 17:00:08 kergoth: so if I set BB_NUMBER_PARSE_THREADS = 1 Jun 16 17:00:13 it should be like old age Jun 16 17:00:16 also make sure you're on a recent bitbake and not being bit by that old python issue with multiprocessing Jun 16 17:00:18 yeah indeed Jun 16 17:00:27 I am on latest all the time Jun 16 17:00:36 thats part of my problems in some sense too Jun 16 17:00:57 but this machine is kind of new to churning oe Jun 16 17:01:05 hehe Jun 16 17:01:07 so I dont know if it always happened or is new Jun 16 17:01:09 still, strange behavior Jun 16 17:01:14 it is Jun 16 17:01:21 could be a bug in multiprocessing itself Jun 16 17:01:26 sometimes it behaved badly when firefox was running Jun 16 17:01:29 you can get races / hangs if things don't happen right with it Jun 16 17:01:39 yeah its racing I think Jun 16 17:01:44 lemme try single cpu Jun 16 17:01:56 could try building a standalone more recent python of the same minor version Jun 16 17:02:55 its running ubuntu 11.04 64bit Jun 16 17:03:06 works fine on a dual core same os Jun 16 17:03:11 64 bit Jun 16 17:03:16 brvb Jun 16 17:04:21 k Jun 16 17:26:12 Is there an easy way of using devshell inside of a running screen? Jun 16 17:32:40 hi all Jun 16 17:34:17 otavio: it creates a new screen session. screen can have any number of them. use screen -l to list the available ones, and try connecting to one of those explicitly by passing it on the screen -r commandline Jun 16 17:34:34 otavio: i have a patchset which fixes this, but it's for oe-core, haven't pulled it over to oe yet Jun 16 17:34:47 kergoth: I am using oe-core ;-) Jun 16 17:39:43 03Tom Rini  07master * r54a91b3957 10openembedded.git/recipes/valgrind/ (3 files in 2 dirs): Jun 16 17:39:43 valgrind: Add patch for PowerPC target support, update recipe Jun 16 17:39:43 The support patch has been merged upstream. Patch found via oe-lite: Jun 16 17:39:43 http://git.doredevelopment.dk/?p=oe-lite/base.git;a=commitdiff;h=6b00807cadec3dd8978d0297181c67f81ec37706 Jun 16 17:39:44 Signed-off-by: Tom Rini Jun 16 17:43:58 Was wondering if recent bitbake versions are no more Interactive, I can't do a -i Jun 16 17:47:25 sorry, I guess its not supported anymore from what I read, thanks anyway Jun 16 17:54:19 otavio: https://github.com/kergoth/oe-core/compare/misc-fixes...devshell, the devshell branch of my github repo is the one, you can merge it into your current branch. See https://github.com/kergoth/oe-core/commit/c9f4e038 and https://github.com/kergoth/oe-core/commit/3928ead Jun 16 17:54:35 otavio: sent it to the list twice now, not been merged yet, not sure why Jun 16 17:54:49 witht he second commit there, you can screen -r devshell Jun 16 17:54:49 RP__: ^ Jun 16 17:54:53 rather than it being unnamed Jun 16 17:56:21 you can see it doesn't retain compatibility with the current TERMCMD/TERMCMDRUN junk, but i think thats' a good thing, personally Jun 16 17:56:25 heh Jun 16 17:58:03 kergoth: I merged it into my tree. Will test it Jun 16 17:58:17 kergoth: mind if I include those in my next pull request? Jun 16 17:58:32 fine with me Jun 16 17:58:34 let me know what you think Jun 16 17:58:39 don't think many people have tested it yet Jun 16 17:58:49 kergoth: in this case I'd rebase those, add the signed-of-by and send Jun 16 17:59:05 kergoth: so more support to those might push for it to be pulled into oe-core Jun 16 17:59:55 * kergoth nods Jun 16 18:00:00 thanks Jun 16 18:00:09 kergoth: in fact it doesn't work for me. I have one running screen session and I runned the devshell Jun 16 18:00:19 kergoth: but it haven't start the session Jun 16 18:00:39 well, if you have a real terminal available and haven't set OE_TERMINAL = "screen", it'll spawn one of those instead Jun 16 18:00:41 kergoth: the only one is there is the one I am using Jun 16 18:00:53 did it say it was spawning screen? Jun 16 18:00:56 it displays a message now Jun 16 18:01:06 NOTE: package cmake-nativesdk-2.8.3-r1.0: task do_devshell: Started Jun 16 18:01:06 WARNING: Screen started. Please connect in another terminal with "screen -r devshell" Jun 16 18:01:19 well, it ran screen -S.. Jun 16 18:01:22 dunno Jun 16 18:01:26 i'll see if i can repro Jun 16 18:01:49 pretty sure it uses the same command that the old one used.. hmmm Jun 16 18:01:54 * kergoth pokes at it Jun 16 18:02:08 kergoth: if I run screen -S foo into my screen it works Jun 16 18:02:19 weird. Jun 16 18:02:29 okay, i'll dive into it, thanks for the info Jun 16 18:02:36 * kergoth hopes he can repro, since it did work here at one point :) Jun 16 18:02:47 i'll make sure i run bitbake from inside screen Jun 16 18:03:17 if you run it with -D, by the way, it should show you what terminals its attempting to use, etc, when using 'auto' Jun 16 18:04:52 1947 pts/2 S 0:00 \_ python /home/otavio/hacking/el/bitbake/bin/bitbake cmake-nativesdk -c devshell Jun 16 18:04:55 1952 ? Ss 0:00 \_ SCREEN -D -m -t OpenEmbedded Developer Shell -S devshell /bin/zsh Jun 16 18:04:59 it seems to be running, indeed Jun 16 18:05:23 hmm, interesting Jun 16 18:05:31 are you running bitbake inside of a chroot or something? Jun 16 18:05:37 kergoth: yes Jun 16 18:05:37 it would use a different location for the screen files if so Jun 16 18:05:46 it stores the list in your homedir, iirc Jun 16 18:06:01 you'd have to connect to it from inside the chroot as well Jun 16 18:06:05 so make sure that's the case Jun 16 18:06:17 i've gotten bit by this, i use schroot to run bitbake in the chroot, but don't enter the chroot myself Jun 16 18:06:25 kergoth: yes, that seems to be the case Jun 16 18:06:29 kergoth: I use schroot Jun 16 18:06:37 kergoth: but I use it interactively Jun 16 18:06:45 as long as your current screen and bitbake are both spawned in the chroot, it shouldn't be an issue Jun 16 18:06:46 * kergoth nods Jun 16 18:06:49 thats probably not it then Jun 16 18:07:04 kergoth: my screen is runned outside of it Jun 16 18:07:11 kergoth: I start screen Jun 16 18:07:15 * kergoth does alias bitbake='schroot -c maverick -p -- bitbake' Jun 16 18:07:37 kergoth: and from it I open the schroot Jun 16 18:07:48 kergoth: but why it might be an issue Jun 16 18:07:49 ? Jun 16 18:07:57 okay, well the key is that your screen -r and the bitbake are both running in the same chroot Jun 16 18:08:02 afaict, anyway Jun 16 18:08:10 if they are, this shouldn't be an issue Jun 16 18:08:35 i haven't had time to investigate the root cause, presumably its storing the info about the screen sessions somewhere that I don't have shared between the two contexts Jun 16 18:08:41 but i don't think this is your issue Jun 16 18:09:09 kergoth: found it Jun 16 18:09:12 * kergoth tries entering the schroot, running screen, and doing a bitbake of devshell Jun 16 18:09:48 kergoth: it was a matter of running -r *inside* the schroot Jun 16 18:09:53 kergoth: it works FINE :-D Jun 16 18:09:58 hehe Jun 16 18:10:00 okay Jun 16 18:10:05 we should probably look into why that's the case Jun 16 18:10:12 but at least we know it isn't an issue most people will hit Jun 16 18:12:09 NOTE: package autoconf-native-2.68-r1: task do_devshell: Started Jun 16 18:12:10 WARNING: Unsupported terminal "rxvt", defaulting to "auto" Jun 16 18:12:10 WARNING: Screen started. Please connect in another terminal with "screen -r devshell" Jun 16 18:12:16 definite improvement, i think :) Jun 16 18:12:43 hmmm Jun 16 18:13:08 otavio: you put $debian_chroot in your shell prompt? really helpful, i've found Jun 16 18:13:21 kergoth: yes, I do Jun 16 18:13:29 kergoth: it helps to know where you're Jun 16 18:13:31 schroot is handy, i'm surprised more people don't know about it Jun 16 18:13:33 yeah Jun 16 18:13:43 i keep meaning to play with containers though Jun 16 18:13:45 they look really intersting Jun 16 18:13:46 kergoth: we use it for our autobuilders Jun 16 18:13:52 like chroot + startup scripts and all Jun 16 18:13:56 cool Jun 16 18:14:07 kergoth: our machine runs using lxc Jun 16 18:14:15 nice Jun 16 18:14:15 kergoth: works quite well Jun 16 18:14:43 someone was ranting about how much the lxc tools suck somewhere recently.. probably landley Jun 16 18:14:46 he's good at rants Jun 16 18:15:02 kergoth: silicon -> (machines) -> builder -> schroot specific for each release Jun 16 18:15:27 kergoth: suck? I enjoy it a lot Jun 16 18:15:43 kergoth: the problem with lxc is that iti s a bit complicate to set up Jun 16 18:15:45 i mean implementation wise, he was talking about how they had like hundreds of lines of shell to do something you can do in 3 Jun 16 18:15:46 hehe Jun 16 18:15:48 * kergoth nods Jun 16 18:16:16 anyone here able to edit the wiki? or give me permissions to do so? :-) Jun 16 18:16:50 I'd like to tidy up http://openembedded.net/index.php/OEandYourDistro a bit, particularly pointing out that if your distro uses Python3 by default you're going to need to make some changes Jun 16 18:16:58 * incandescant raises an eyebrow at Arch Jun 16 18:23:17 incandescant: good idea Jun 16 18:24:30 * kergoth has no idea wrt permissions though Jun 16 18:25:06 * incandescant will try again in a couple hours and if not hit the list for assistance Jun 16 18:25:32 python3 by default is an awfully ballsy move, considering how many modules/packages don't support it yet Jun 16 18:26:01 no kidding, I had thought about giving arch a go but that's not a world of pain I want to partake in :-) Jun 16 18:26:16 I really like the shiny Py3k future, but it's still definitely *future* Jun 16 18:26:39 * kergoth nods Jun 16 18:26:53 incandescant: ka6sox-away may give you login Jun 16 18:27:16 or paste your markup somewhere and I'll add it Jun 16 18:28:00 * Jay7 have tried on Arch but scared by python == python3 by default Jun 16 18:28:16 so lxc with debian inside was quicker and easier solution :) Jun 16 18:28:21 hehe Jun 16 18:29:32 * kergoth decides to try tracking down git repositories for upstreams for some of the bits in oe-core/meta/recipes-core/ as a background task Jun 16 18:30:38 anyone messed with custom merge drivers for git, by chance? Jun 16 18:30:41 * kergoth reads the docs about it Jun 16 18:40:36 kergoth: why you'd like to use custom merge drivers? Jun 16 18:40:49 there are multiple use cases Jun 16 18:41:07 the one i'm thinking abuot, which i've hit before, is where you're tracking an upstream, but remove some dirs you don't care about Jun 16 18:41:19 now every tiem you merge from upstream, when upstream changes a removed file, you hit a conflict Jun 16 18:41:28 so it makes sense to be able to say 'always use my version of any file in this dir' Jun 16 18:42:44 Jay7, thanks. If you wouldn't mind adding I've pasted an edited Required_software: http://pastebin.com/3gZ2znHY and OEandYourDistro http://pastebin.com/93breQtJ Jun 16 18:44:55 incandescant: will do Jun 16 18:45:28 thanks a lot Jun 16 18:48:46 kergoth: ok if I use BB_NUMBER_PARSE_THREADS = 1 Jun 16 18:48:51 all works hunky dory Jun 16 18:50:55 kergoth: system is not frozen anymore so I would say its faster for me use 1 thread then to let bb decide :) Jun 16 18:52:06 khem: weird Jun 16 18:52:16 likely something upw ith the multiprocessing module on that machine Jun 16 18:52:57 kergoth: when I use 4 its still ok atleast system is not frozen Jun 16 18:53:05 incandescant: done Jun 16 18:53:10 please check Jun 16 18:55:21 kergoth: I spoke too soon Jun 16 18:55:29 kergoth: with 4 it hangs same way Jun 16 18:55:34 I have to kill python Jun 16 18:55:55 and to get to another shell to type pkill python it take roughly 4 minutes Jun 16 18:56:26 * khem tries 2 Jun 16 18:56:38 i'd try a different python version, at least isolate it to the behavior of multiprocessing itself vs bitbake Jun 16 18:56:52 kergoth: I have two disks and I see activity on both Jun 16 18:57:01 so it seems its using lot of swap space Jun 16 18:57:21 * otavio redoes a rebase and hope for the best Jun 16 18:57:22 hehe Jun 16 18:57:23 lol Jun 16 18:58:05 same problem with 2 Jun 16 18:58:19 so it seems as soon as multicore kicks in it starts to act Jun 16 18:58:29 lemme try another python Jun 16 18:59:58 Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) Jun 16 18:59:58 [GCC 4.5.2] on linux2 Jun 16 19:00:03 this is the current version Jun 16 19:03:44 * khem tried 2.6 Jun 16 19:04:35 thanks Jay7, I think I fluffed the grammar a bit but I will try and get a wiki account from ka6sox-away Jun 16 19:06:07 kergoth: same problem with 2.6 Jun 16 19:06:20 kergoth: it seems that after parsing it sits there forever Jun 16 19:06:34 never reaches runqueue stage Jun 16 19:07:30 morning kergoth Jun 16 19:07:38 hey Jun 16 19:07:48 hi pb_ Jun 16 19:07:53 hi khem Jun 16 19:07:59 pb_: is your hosue done yet ? Jun 16 19:08:03 house Jun 16 19:08:09 not quite. getting there. Jun 16 19:08:23 plumbing going in at the moment Jun 16 19:08:30 pb_: once you move in is what I call the finish line :) Jun 16 19:08:37 heh Jun 16 19:08:40 because you keep working on it as long as you live Jun 16 19:08:58 yeah, still not actually living in it at the moment. probably another few weeks. Jun 16 19:09:03 ok Jun 16 19:10:16 pb_: made from scratch? Jun 16 19:10:25 no, refurbishment and extension Jun 16 19:10:31 pb_: i see Jun 16 19:10:37 otavio: incremental build :) Jun 16 19:10:38 though it would have been easier to knock it down and build a new one :-} Jun 16 19:10:59 pb_: it usually takes longer then spected Jun 16 19:10:59 pb_: lol Jun 16 19:11:55 kergoth: i signed-of the commits; once i finish the cmake stuff I will send them all Jun 16 19:12:30 otavio: k, cool Jun 16 19:12:44 kergoth: they do worked fine :-) Jun 16 19:12:52 great Jun 16 19:14:04 kergoth: I still see more than 1 python instances when I use 1 for BB_NUMBER_PARSE_THREADS Jun 16 19:14:40 khem: that's not surprising Jun 16 19:14:47 it just forks off one parsing thread instead of many Jun 16 19:14:54 it doesn't do the work in the current process ever Jun 16 19:14:55 is it a know issue: WARNING: QA Issue: package perl-module-compress contains bad RPATH /home/otavio/hacking/el/tmp-eglibc-eglibc/sysroots/ossystems-x86/usr/lib in file /home/otavio/hacking/el/tmp-eglibc-eglibc/work/i586-oe-linux/perl-5.12.3-r1/packages-split/perl-module-compress/usr/lib/perl/5.12.3/auto/Compress/Raw/Zlib/Zlib.so Jun 16 19:15:00 NOTE: package perl-5.12.3-r1: task do_package: Succeeded Jun 16 19:15:02 ? Jun 16 19:15:31 kergoth: ok Jun 16 19:15:46 for this machine I am going to stick with BB_NUMBER_PARSE_THREADS =1 I guess Jun 16 19:16:15 it take about 40s with 1 thread which is fine Jun 16 19:16:36 no clue what's happening there. maybe i can look into it by ssh'ing into that box at some point Jun 16 19:16:38 * kergoth shrugs Jun 16 19:16:55 same distro on another hardware works fine Jun 16 19:17:08 and even there I have two disks Jun 16 19:17:17 so it could be how the stuff is set up Jun 16 19:17:58 kergoth: this box is super secure even I cant access it from outside Jun 16 19:18:00 :) Jun 16 19:18:24 ICFPC 2011 is starting soon Jun 16 19:18:24 such boxes should remain in such high security only think dont let anyone get into them Jun 16 19:18:36 makes them very productive :) Jun 16 19:18:50 khem: heh, no idea how to go about fixing it then :) Jun 16 19:18:58 hopefully we can find a way to repro it, or someone else hits it in the future Jun 16 19:19:05 You can hint me Jun 16 19:19:19 kergoth: is there some way to get stack trace Jun 16 19:19:23 of events its doing Jun 16 19:19:34 so I can check whats being executing Jun 16 19:19:46 or it is just that its waiting on some rogue signal Jun 16 19:19:49 you can use python -m trace, but that shows every line of python it runs, it's way too verbose Jun 16 19:19:52 it's not that simple Jun 16 19:20:08 hmm threaded programming it is right Jun 16 19:20:13 its likely the process went to exit, which joins the running threads, and one of those won't exit for some reason Jun 16 19:20:18 could be a deadlock, waiting on one another Jun 16 19:20:25 not easy to determine that Jun 16 19:20:31 but it should not eat cpu Jun 16 19:20:41 and keep spinning the primary disk Jun 16 19:20:44 we're using multiple processes, but there are still actual threads involved Jun 16 19:20:58 the multiprocessing queue uses a thread to feed the queue, so you don't block when adding items to it Jun 16 19:21:04 rewrite bb in golang Jun 16 19:21:13 so if you don't clear the queue on the other end, that feeder thread will never finish Jun 16 19:21:16 and then you hang on exit Jun 16 19:21:20 (ran into this one before) Jun 16 19:21:24 dunno what you're hitting though Jun 16 19:21:29 if its doing stuff, that doesn't sound like this issue Jun 16 19:21:49 you could try adding some bb.notes to cooker.py, in the CookerParser class Jun 16 19:21:52 actually when Ctrl-C bb it exits but python keeps spinning Jun 16 19:21:57 specifically, the parse_next function Jun 16 19:21:57 so I have pkill python Jun 16 19:22:15 weird, we specifically catch SIGINT and shut down the server process Jun 16 19:22:21 so something is really weird going on Jun 16 19:22:29 so it seems Jun 16 19:22:41 but server gets tinkered in Jun 16 19:22:44 everyday Jun 16 19:22:57 well this problem is about month long now on this box Jun 16 19:23:12 and before than no history Jun 16 19:23:48 Does it access something from homedir ? Jun 16 19:24:01 because homedir on this box is nfsmounted Jun 16 19:24:11 and it uses NIS for automounting Jun 16 19:24:16 don't think bitbake itself does. we don't have any dotfiles or anything Jun 16 19:24:29 potentially something in the metadata could be running something which uses the homedir Jun 16 19:24:30 well thats one difference I see Jun 16 19:24:36 e.g. git for srcrev uses ~/.gitconfig Jun 16 19:24:45 which I have Jun 16 19:25:08 ah let me login as local user Jun 16 19:25:10 and retry Jun 16 19:25:31 k Jun 16 19:26:08 only if I rememver passwd Jun 16 19:27:07 hehe Jun 16 19:27:09 gosh Jun 16 19:33:11 morning Jun 16 19:39:16 kergoth: another data point is when I build more than 1 machines that when it start happening Jun 16 19:39:27 if I nuke builddir and start fresh is works ok Jun 16 19:39:32 weird Jun 16 19:41:49 kergoth: where is cache kept ? Jun 16 19:42:05 kergoth: I can try to sweep it away for test Jun 16 19:42:10 hi khem kergoth Jun 16 19:42:22 chouimat: hellp Jun 16 19:43:40 khem: I'm currently rusty, I spent the last 2 and half months weary my business hat ... aka no coding at all :) Jun 16 19:47:31 khem: tmpdir/cache Jun 16 19:47:44 anyone know where dropbear is developed? the cvs repo is "historical", but no info is given about a replacement Jun 16 19:48:10 kergoth: I have so many .lock files in there Jun 16 19:48:21 kergoth: try to find ML Jun 16 19:48:26 the caching stuff changed recently.. Jun 16 19:48:31 kergoth: I think because I deleted so many runs in between Jun 16 19:48:46 khem: could try with bitbake before hte cache changes Jun 16 19:48:48 25M 2011-06-16 12:12 bb_codeparser.dat Jun 16 19:49:00 so is the cache per machine ? Jun 16 19:49:06 or just one big cache Jun 16 19:50:06 hmmm so oe-core we have two tmpdirs Jun 16 19:50:24 and both have cache dir underneath Jun 16 19:50:33 but contents are different Jun 16 19:51:22 kraj@kraj-lnx:/b/angstrom/build/tmp-angstrom_2010_x/cache Jun 16 19:51:22 $ ls Jun 16 19:51:22 bb_codeparser.dat bb_persist_data.sqlite3 Jun 16 19:51:27 $ ls ../../tmp-angstrom_2010_x-eglibc/cache/ Jun 16 19:51:27 bb_persist_data.sqlite3 default-eglibc Jun 16 19:51:47 so bb_persist_data.sqlite3 is in both dirs Jun 16 19:53:38 kergoth: could this confuse bb ? Jun 16 19:54:14 the issue there is someone is using overrides or _append/_prepend with TMPDIR Jun 16 19:54:19 but TMPDIR is used before those things are applied Jun 16 19:54:23 so part of thte ubild uses one, part the other Jun 16 19:54:26 i've noticed this too Jun 16 19:54:29 but it doesn't seem to cause a problem Jun 16 19:54:54 erk, dropbear uses monotone? Jun 16 19:55:03 i thought i'd never have to use that again Jun 16 20:25:37 whew, there we go, got a export script to keep a current git mirror of the dropbear mtn repo Jun 16 20:27:18 is monotone still alive? Jun 16 20:33:33 ka6sox-farfarawa: no clue Jun 16 21:17:39 Do someone have any clue about the build failure show at http://paste.debian.net/120114 <= WIP cmake-nativesdk Jun 16 21:33:25 otavio: are you using gcc-crosssdk ? Jun 16 21:33:47 otavio: if yes then it seems its missing libstdc++-nativesdk Jun 16 22:15:38 khem: I'm ignoring the various fixes for compiling with gcc-4.6.0. This will never be backported to oe-dev, isn't? Jun 16 22:16:05 ant__: no Jun 16 22:16:25 ant__: you should ideally start using oe-core + meta-oe Jun 16 22:16:36 ok, then oe-dev doesn't need such patches Jun 16 22:16:46 yes Jun 16 22:16:54 sure, I'm closing the windows before leaving ampty holuse ;) Jun 16 22:17:01 heh Jun 16 22:17:16 argh..typing in the dark Jun 16 22:17:20 all fun is in oe-core + meta-oe these days Jun 16 22:17:50 yes, I'll have to host a temporary layer though Jun 16 22:18:57 ant__: what will this layer have ? Jun 16 22:19:15 we can put it under meta-openembedded if its a common enough layer Jun 16 22:19:15 soem kernel defconfigs, klibc recipes Jun 16 22:19:30 ant__: which machines Jun 16 22:19:41 ant__: is it kexec things Jun 16 22:19:50 heh, meta-handhelds Jun 16 22:19:58 yup Jun 16 22:20:43 do you think klibc recipes should be hosted in a separate layer? Jun 16 22:20:56 I mean, recipes building against klibc Jun 16 22:21:20 I suppose many other would compile, I just never tested Jun 16 22:22:27 imho this is not meta-handhelds Jun 16 22:24:49 well klibc can live in meta-oe/recipes-core Jun 16 22:25:13 right now I think it is just used for few recipes images but it can be enhanced Jun 16 22:25:24 yes, just inheriting klibc Jun 16 23:12:45 cbrake: testing-next snap happening? Jun 16 23:23:38 hi Jun 16 23:24:14 I'd like to do that in oe.dev in bitbake.conf(I'll send a patch) : Jun 16 23:24:16 -LZMA_COMPRESSION_LEVEL ?= "-e -9" Jun 16 23:24:17 +LZMA_COMPRESSION_LEVEL ?= "-9" Jun 16 23:24:27 because -e is not an lzma option Jun 16 23:24:34 and so it breaks kexecboot Jun 16 23:24:49 I could override in machine config Jun 16 23:24:55 but that would fix for one machine only Jun 16 23:28:52 Didn't we go over all that already? Jun 16 23:29:02 yes we did Jun 16 23:29:25 else I wouldn't know it was LZMA_COMPRESSION_LEVEL Jun 16 23:29:32 I'll look at the logs Jun 16 23:42:29 May 04 00:22:52 GNUtoo|laptop: we have it overriden in machine confs iirc Jun 16 23:42:34 that's what I've been told Jun 16 23:42:45 but I wonder if fixing for everybody is better Jun 16 23:49:49 hmmm I made some error with SHR Jun 16 23:50:07 there is a kexecboot-cfg package Jun 16 23:50:20 I didn't used it Jun 16 23:50:37 *use Jun 17 00:01:21 Hi. I'm going through my first openembedded install, and I get this: http://pastebin.com/DU5j7U5L Jun 17 00:04:31 Any way to get around an error like this? Jun 17 00:23:35 For git:// SRC_URIs, what are allowed protocol parameters? Is it simply protocol=git and protocol=file? How about ssh? Jun 17 00:25:53 delirus: are you using oe.dev ? Jun 17 00:26:21 delirus: it may not be in best shape to use .dev Jun 17 00:30:33 zenlinux_laptop, http is allowed too Jun 17 00:32:11 GNUtoo, thanks. I'm looking at having bitbake's git fetcher raise a ParameterError exception if protocol is specified but it not set to git|file|ssh|http|https Jun 17 00:32:39 ok Jun 17 00:33:10 to make its error reporting friendlier when something bogus is set for protocol, which Phil B. noted makes bitbake's output decidedly unfriendly Jun 17 00:45:36 After I modify a recipe, is there a way for me to know what was rebuilt, so that I may replace only those components in my board's filesystem? Jun 17 00:50:09 okay, tracking down old versions of libjpeg is a royal pain Jun 17 00:50:15 why do they have to do things so weirdly Jun 17 00:50:22 * kergoth mutters Jun 17 01:03:02 whew, got em all Jun 17 01:03:21 now to get a clean workflow using pristine-tar **** ENDING LOGGING AT Fri Jun 17 02:59:56 2011