**** BEGIN LOGGING AT Wed Mar 31 02:59:56 2010 Mar 31 03:18:08 aha, i see.. Mar 31 03:31:17 Interesting...if i use the file executable from the src directory (4.04 it works) but verison 5.04 in the staging directory does not work with the provided magic file. Mar 31 03:31:35 Must be some version incompatibility between 5.X and 4.X Mar 31 06:08:31 03Roman I Khimov  07org.openembedded.dev * rc1aab90e5e 10openembedded.git/removal.txt: (log message trimmed) Mar 31 06:08:31 removal.txt: proposal to remove ClamAV versions < 0.95 in April Mar 31 06:08:31 http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/ Mar 31 06:08:31 Without database updates AV is almost completely useless, and Mar 31 06:08:31 starting on April 15 2010 ClamAV < 0.95 will get no db updates, Mar 31 06:08:32 so there is no reason to support that versions. Mar 31 06:08:33 Signed-off-by: Roman I Khimov Mar 31 06:49:02 03Roman I Khimov  07org.openembedded.dev * r2f196b1407 10openembedded.git/recipes/openssl/ (8 files in 2 dirs): Mar 31 06:49:02 openssl: add version 1.0.0 Mar 31 06:49:02 * DEFAULT_PREFERENCE = "-1", since it might break apps Mar 31 06:49:02 * enable engines build (and package those separately) Mar 31 06:49:02 Signed-off-by: Roman I Khimov Mar 31 07:50:15 thebohemian: sigh... kmail crashed twice when replying... Mar 31 07:53:13 zecke: oh Mar 31 07:55:10 good morning Mar 31 08:20:55 morning Mar 31 08:55:43 03Sebastian Spaeth  07org.openembedded.dev * rf902b356c7 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Mar 31 08:55:43 sane-srcrevs: bump shr-settings Mar 31 08:55:43 Signed-off-by: Sebastian Spaeth Mar 31 08:59:27 morning Mar 31 08:59:34 hi ant_work Mar 31 08:59:41 ant_work: how goes kexecboot stuff? Mar 31 09:00:00 well, we are ok on armv5te Mar 31 09:00:09 it seems beagle is not yet ready.. Mar 31 09:00:13 kernel issues Mar 31 09:00:49 (we still have no power man with 2.6.34 on Zaurus...) Mar 31 09:00:52 btw Mar 31 09:00:59 ftp://elsie.nci.nih.gov/pub/tzdata2010f.tar.gz Mar 31 09:01:07 ^^ was removed* Mar 31 09:01:15 in favor of 2010g Mar 31 09:01:18 g was released Mar 31 09:01:19 03Martin Jansa  07org.openembedded.dev * r6a665a12bb 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Mar 31 09:01:19 shr: prefer glib-2.0_2.23.6 Mar 31 09:01:19 Signed-off-by: Martin Jansa Mar 31 09:01:21 03Enrico Scholz  07org.openembedded.dev * rb98084cc22 10openembedded.git/recipes/tcpdump/ (files/configure.patch tcpdump_4.0.0.bb): Mar 31 09:01:21 tcpdump: fixed build with newer autoconf-2.65 Mar 31 09:01:21 Signed-off-by: Martin Jansa Mar 31 09:01:21 03Martin Jansa  07org.openembedded.dev * rf02d3d040e 10openembedded.git/recipes/xorg-xserver/xserver-xorg_git.bb: Mar 31 09:01:22 xserver-xorg: bump SRCREV Mar 31 09:01:22 Signed-off-by: Martin Jansa Mar 31 09:01:33 03Martin Jansa  07org.openembedded.dev * r50b10afbda 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Mar 31 09:01:33 EFL: another SRCREV bump, more efreet fixes and illume2/illume-keyboard fixes reported by Tom 'TAsn' Hacohen Mar 31 09:01:33 Signed-off-by: Martin Jansa Mar 31 09:01:35 hrw: because of that crazy ussian changes ;) Mar 31 09:01:44 03Martin Jansa  07org.openembedded.dev * rcc25e6b8ba 10openembedded.git/ (3 files in 3 dirs): Mar 31 09:01:44 mesa-dri_7.8: add patch with glamo support and prefer it with SHR Mar 31 09:01:44 Signed-off-by: Martin Jansa Mar 31 09:01:45 ant_work: did you saw CONFIG_EXT4_USE_FOR_EXT23 option? Mar 31 09:01:58 hm..not yet Mar 31 09:02:14 maybe it is after .33 stuff Mar 31 09:02:32 but will give you smaller kernel Mar 31 09:02:36 well, for nand we are still on jffs2, waiting ubifs Mar 31 09:02:53 do you suggest ext4 for SD/CF ? Mar 31 09:03:06 or usb disks? Mar 31 09:03:28 I onlyread about ext4 bugs ... Mar 31 09:03:45 no no no Mar 31 09:03:56 he Mar 31 09:04:10 this makes ext4.ko to handle ext2 ext3 filesystems as ext2/ext3 Mar 31 09:04:17 less code in kernel Mar 31 09:04:25 yea, one for all Mar 31 09:04:32 I am using ext4 on all my machines for some time now Mar 31 09:04:39 issues? Mar 31 09:04:56 none so far Mar 31 09:05:13 CONFIG_EXT4_USE_FOR_EXT23 should be in .33 anyway Mar 31 09:05:29 now hat you say..perhaps is already used in the 2.6.33 Mar 31 09:05:53 not in linux-kexecboot 2.6.33 Mar 31 09:06:28 bb in few Mar 31 09:06:41 ok, thyx for the pointer Mar 31 09:15:57 Apparently no version of xf86-input-elographics can compile agains xserver-xorg 1.7.3. Do anyone know which combination of xserver-xorg and xf86-input-elographics that works ? Mar 31 09:23:58 hi Mar 31 09:24:08 are the OE forum down? Mar 31 09:25:17 mimecar: there is no OE forum. Mar 31 09:26:08 from www.oesf.org Mar 31 09:26:35 ok Mar 31 09:26:46 mimecar: sorry, you ask the wrong kind of people. :) Mar 31 09:27:07 thanks for your reply zecke Mar 31 09:27:15 I'll search better ;) Mar 31 09:27:18 hrw: about that ext2-3-4 driver: http://www.linuxquestions.org/questions/slackware-14/dev-root-ext4-fs-being-mounted-ext2-fs-797354/ Mar 31 09:27:54 mimecar: the story is, they took the name "Open Embedded" and put Software Foundation at the end, besides taking our name there is no relationship Mar 31 09:28:22 I thought both webs were related Mar 31 09:29:15 mimecar: it's just most Zaurus developers form there migrated here Mar 31 09:29:36 ~oesf Mar 31 09:29:37 somebody said oesf was rumour has it, oesf is newer name of ZUG - it provides forum for Zaurus/Ipaq/Simpad/etc users (see zug). It has nothing in common with OpenEmbedded (except for the first two letters), see http://www.oesf.org/ Mar 31 09:29:55 ~factinfo oesf Mar 31 09:29:55 oesf -- created by Laibsch at Sun Oct 22 20:07:44 2006 (1255 days); it has been requested 5 times, last by hrw, 19s ago. Mar 31 09:31:21 ok Mar 31 09:31:51 ant_work: kexecboot kernel mounts cards just to read kernels from them - not to store something Mar 31 09:32:29 yes, it's up to the target kernel to be able to read the fs Mar 31 09:33:19 but this sounds wrong... Mar 31 09:33:20 So, for a EXT4FS root partition, kernel try to use EXT3FS, EXT2FS and finally EXT4FS driver. In your case, the EXT4FS driver also support EXT2. After EXT3FS driver gracious protest that this baby is not his problem, EXT4FS driver accept to mount the root partition AS EXT2. Mar 31 09:33:57 I'll do some tests Mar 31 09:36:23 03Sebastian Spaeth  07org.openembedded.dev * rd59fe293e2 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Mar 31 09:36:23 sane-srcrevs: bump SHR's phone* applications to current Mar 31 09:36:23 Signed-off-by: Sebastian Spaeth Mar 31 09:36:33 03Sebastian Spaeth  07org.openembedded.dev * rfb3a5d2a52 10openembedded.git/: Merge branch 'org.openembedded.dev' of ssh+git://git@git.openembedded.net/openembedded into org.openembedded.dev Mar 31 09:36:35 hrw: about devtmps...being that kexecboot recreates the device nodes..I think it's superfluous. Any opinion? Mar 31 09:36:43 03Sebastian Spaeth  07org.openembedded.dev * re282c6c3ce 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Mar 31 09:36:43 sane-srcrevs: bump e-wm-config-illume-shr to current Mar 31 09:36:43 The old version had a press delay of 0, which automatically made apps start when scrolling the illume background, it seems. Mar 31 09:36:43 Signed-off-by: Sebastian Spaeth Mar 31 09:37:11 hrw: *devtmpfs of course Mar 31 09:43:47 oh... I read in kexec mailing-list they are working on uImage Mar 31 09:43:50 ant_work: did not used devtmpfs yet Mar 31 09:43:54 "It seems that ARM's and SH's uImage are always uncompressed so it might Mar 31 09:43:56 be good to check for this." Mar 31 09:44:05 always ? Mar 31 09:46:20 in kernel.bbclass we have : if test -e arch/${ARCH}/boot/compressed/vmlinux ; then Mar 31 09:46:36 uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C none ... Mar 31 09:46:46 else Mar 31 09:46:49 -C gzip Mar 31 09:47:59 who would not use the compressed/vmlinux ? Mar 31 10:04:25 hi,I still have that for m4 under angstrom: Mar 31 10:04:27 | configure.ac:25: require Automake 1.11.1, but have 1.10.3 Mar 31 10:04:37 i've preferred 1.11.1 tough Mar 31 10:04:49 and cleaned old automake and bitbaken 1.1.11 Mar 31 10:05:05 but still automake likes to 1.10.3 Mar 31 10:08:57 *linkes Mar 31 10:14:10 angstrom uses 1.10.3 Mar 31 10:14:47 I saw that but m4 wants 1.1.11 Mar 31 10:15:39 recipes/m4/m4_1.4.14.bb Mar 31 10:19:10 basically prefering 1.1.11 on nativ and non-native Mar 31 10:19:23 anc cleaning 1.1.10 Mar 31 10:19:37 and rebuiliding automake Mar 31 10:19:44 and native Mar 31 10:19:53 and cleaning and rebuilding m4 Mar 31 10:19:56 didn't change a thing Mar 31 10:26:48 morning all Mar 31 10:30:10 hi RP Mar 31 10:31:03 mimecar: it is bad that oesf.org died but I think that it was expected as amount of zaurus users changes each month Mar 31 10:32:02 that's true Mar 31 10:32:56 the're new devices currently, with better features Mar 31 10:34:21 and today phones often works better then zaurus devices for some tasks Mar 31 10:35:10 you can find wifi , BT or GPS on mobile phones Mar 31 10:35:18 I moved from c760 to se k750i phone with my PIM tasks, then added n810 to it for web/chat/walknavigation Mar 31 10:35:20 on zaurus you got wifi with a cf card Mar 31 10:35:46 then moved to nokia e66 phone and stopped using k750i and n810. now I have nokia n900 Mar 31 10:35:56 mimecar: I had 3 wifi cf cards Mar 31 10:36:08 two 802.11b and one 802.11g Mar 31 10:36:16 n900 it's a nice device Mar 31 10:36:32 thats reminds me one thing - I found SL-6000L docking station in basement Mar 31 10:36:47 yes, it is. software suxx in many places but hw is nice Mar 31 10:37:56 I've my "old" zaurus, C1000, and it works ok for my needs Mar 31 10:38:13 I've test develop some apps, but it's not posible Mar 31 10:39:55 c1000 is not so old ;D Mar 31 10:40:31 and is one of those which I did not had at home ;) Mar 31 10:40:46 xD Mar 31 10:40:56 strange... Mar 31 10:40:58 it's my ebook reader Mar 31 10:41:09 bitbake m4 pulls automak 1.10.3 Mar 31 10:42:03 but preferred version is set to 1.11.1 Mar 31 10:43:18 GNUtoo|oeee, prefered version on bitkabe recipie, don't you? Mar 31 10:44:17 03Sebastian Spaeth  07org.openembedded.dev * rd36c91f616 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Mar 31 10:44:17 sane-srcrevs: bump libphone-ui-shr again Mar 31 10:44:17 THe previous one turned out to contain a flawed commit that is reverted now. Mar 31 10:44:17 Signed-off-by: Sebastian Spaeth Mar 31 10:45:21 in local.conf Mar 31 10:46:42 GNUtoo|oeee, I think you should update recipie Mar 31 10:47:16 which one? Mar 31 10:48:09 m4 recipie Mar 31 10:48:30 if you want it use automake 1.11.1 Mar 31 10:48:52 ok Mar 31 10:48:54 thanks a lot Mar 31 10:49:06 backup original recipie first Mar 31 10:52:15 there is noting interesting inside it,also: Mar 31 10:52:42 (version) are not enforced as far as I know Mar 31 10:54:11 maybe I'll downgrade m4 Mar 31 11:03:33 ok downgrading m4 seem to work Mar 31 11:05:39 cool Mar 31 11:06:57 GNUtoo|oeee, I down graded m4 and autoconf I think. Did a clean build last night - didn't get any problems from that change... Mar 31 11:08:34 GNUtoo|oeee: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=bc13fe86a5b8f2c1aaa40bde39d7a2de1ccd48f3 Mar 31 11:08:52 this should have solved the issue, isn't? Mar 31 11:38:11 hello guys (and girls?). I am trying to bitbake latest Angstrom x11-image, and it fails on tzcode-native_2010f.bb Mar 31 11:38:41 as it can not fetch fetch http://mirrors.openembedded.org//tzdata2010f.tar.gz Mar 31 11:38:59 is there anything wrong with this sources? Mar 31 11:39:30 It should not be the firewall problem, as I am using open network, with no restrictions Mar 31 11:39:57 but it is strange, that ftp and http server does not respond Mar 31 11:40:22 can you download that file with PC? Mar 31 11:40:28 nope Mar 31 11:40:32 and can you? Mar 31 11:40:37 404 ERR Mar 31 11:41:35 http://www.angstrom-distribution.org/unstable/sources/tzdata2010f.tar.gz seems to fail either Mar 31 11:41:38 I don't Mar 31 11:41:46 it looks that file is missing Mar 31 11:41:53 well. That seems to be the problem than ;] Mar 31 11:42:10 mimecar: how is it resolved usually? Mar 31 11:42:49 it's a server error Mar 31 11:42:56 should i get this package from somewhere else, or just wait patiently? Mar 31 11:43:01 you can wait or download that file froma mirror Mar 31 11:43:35 shouldn't be all mirrors listed in reciepe, so bb would ahndle this automatically Mar 31 11:43:35 ? Mar 31 11:44:28 just for the record - this problem persists for about 30hrs now Mar 31 11:44:44 (if i am not screwed by my very disturbed memory) Mar 31 11:50:56 nazgee, is there a bug report? Mar 31 11:51:12 mimecar: nope Mar 31 11:51:28 at least not yet Mar 31 11:52:02 then, the problem will persist more Mar 31 11:52:14 heh ;] Mar 31 11:52:34 i culd have figure this out myself Mar 31 11:52:52 but i thought that such issues are resolved on-flight Mar 31 11:52:54 ;] Mar 31 11:53:28 god mode on :P Mar 31 11:57:05 ok..see here Mar 31 11:57:06 http://blog.gmane.org/gmane.comp.time.tz Mar 31 11:57:24 fwiw Gentoo mirrors removed the source it seems Mar 31 11:57:57 ...Those wanting to avoid version thrash Mar 31 11:57:58 may want to wait for data2010h... Mar 31 11:59:44 well. probably not me, as i have to force my build going Mar 31 11:59:57 thank you Mar 31 12:00:04 just grab a copy around then, and recreate the md5 Mar 31 12:00:53 but 3-4 releases in a month is a bit silly.... Mar 31 12:01:29 yup. speed makes me dizzy :) Mar 31 12:01:51 dhould i issue a bug report? Mar 31 12:01:55 *should Mar 31 12:02:47 well, good idea, I don't see any specific maintainer for that recipe Mar 31 12:03:28 I'd just post on the ML, no need to open a bug Mar 31 12:05:22 damn it. I could have waited a while ;] I've just opened a bug report ;] Mar 31 12:05:35 np Mar 31 12:06:14 hi, all! Mar 31 12:06:35 the fact is bugs appears on openembedded-commits ML, not so much visibility there Mar 31 12:07:32 would'n it be better have them landing in openembedded-devel? Mar 31 12:09:04 As ther is more attention on toolchain pieces now, is it possible to look into possibility to make profiling glibc recipe? It will make more accurete results from things like gprof. Any thoughts? Mar 31 12:09:08 RP: Mar 31 12:09:25 ant_work: The counterargument ist hat too much automated stuff just results in people unsubscribing, or otherwise not reading, the ML. Mar 31 12:10:29 well, having all the git patches posted here did sometimes hog the ML Mar 31 12:10:45 I don't think a dozen of bugs per monmth could make it worst Mar 31 12:11:50 broonie: sometimes oe-dev was similar to linux-arm-kernel Mar 31 12:11:55 :D Mar 31 12:12:32 hrw, I had to make a minor tweak to busybox-alt, but the proper-tools part built fine overnight. Mar 31 12:12:44 ant_work: don't ask me, as it is not up to me ;] On the other hand, I am not a bb/oe developer, but staying on-time with all the mails there is a bit... overwhelming ;] Mar 31 12:12:51 cool Mar 31 12:13:19 hrw, still need to run test it though Mar 31 12:14:40 There's also the discussion on them and stuff as well; half the problem is that bugmail from BTSs is rarely good for human reading or intended for replies. Mar 31 12:15:18 nazgee: done Mar 31 12:15:44 broonie: right Mar 31 12:16:45 hi all Mar 31 12:16:58 pb_, lo Mar 31 12:17:26 pb__: wb Mar 31 12:17:52 ant_work: thanks Mar 31 12:19:53 ant_work, nice thanks a lot Mar 31 12:20:06 MWelchUK_work_, I downgraded only m4 and it worked Mar 31 12:20:20 hrw, think we need to include nfs-utils as well. They seem to be needed for nfs mounting. Mar 31 12:21:22 ok Mar 31 12:21:24 GNUtoo|oeee, ok. Is your build up-to-date enough to have the modification ant_work mentioned in it (i.e. does that not fix it)? Mar 31 12:25:14 MWelchUK_work_, it's not Mar 31 12:25:58 I'm at dca5bfe78fe4336ef28326a57e3826f97c139942 Mar 31 12:26:04 Ok, I'l probably remove my tweak tonight and try building the updated tree. Mar 31 12:26:53 hi pb__ Mar 31 12:27:15 slapin: I don't see why we can't have some option to enable it. I'm not familiar enough with the specifics to comment though Mar 31 12:27:22 pb__: Did you see my gcc-runtime recipe? Mar 31 12:28:15 GNUtoo|oeee: I rebuilt last night with the actual GNU toolchain Mar 31 12:28:23 ok Mar 31 12:28:38 only issues where with fetching sources :) Mar 31 12:28:44 MWelchUK_work_: btw - does your system has networking working properly? Mar 31 12:28:48 nice Mar 31 12:28:53 MWelchUK_work_: /var/run/dhclient.eth1.pid: interface name too long (max 26) Mar 31 12:29:00 MWelchUK_work_: thats what I got Mar 31 12:31:20 I get "can't create /var/lib/dhcp/dhclient.eth0.leases: No such file or directory" Mar 31 12:31:29 mkdir /var/lib/dhcp/ Mar 31 12:32:04 hrw, and hwclock has differing parameters so the script isn't working right. Mar 31 12:32:42 hrw, guess that should be added to the dhcp recipe. Mar 31 12:33:03 yep Mar 31 12:33:13 MWelchUK_work_: I will try ifupdown 0.6.10 Mar 31 12:33:52 * MWelchUK_work_ is just building a different image, so fiddling will have to wait a few minutes. Mar 31 12:42:05 hi, about security in oe: http://pastebin.com/PsDGsyfk Mar 31 12:42:56 I'll check if there is version n in oe after my last pull Mar 31 12:43:41 http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?id=2f196b1407bd290a4a96d81e99534ccf04b33f1a Mar 31 12:43:43 ok nice Mar 31 12:43:57 hrw, /var/lib/dhcp3/ exists, I assume that this is a naming thing. Mar 31 12:44:05 but default preference = -1 Mar 31 12:47:12 hrw, lol - look in recipes/dhcp/dhcp3.inc Mar 31 12:47:51 In compile: -D_PATH_DHCLIENT_DB=\"/var/lib/dhcp/dhclient.leases\" Mar 31 12:48:01 In install: install -d ${D}/var/lib/dhcp3 Mar 31 12:48:24 auch Mar 31 12:50:27 the problem suxx even more because my test device has broken ethernet Mar 31 12:52:00 hrw: it makes thing easier to test, if you cant do it anyway, doesn't it? Mar 31 12:52:07 ;] Mar 31 12:52:25 nazgee: I have wifi on board Mar 31 12:53:36 hrw: cool. i'm juts curious- what board are u using? Mar 31 12:53:49 bug 2.0 Mar 31 12:54:34 is it possible ot override busybox config just in overlay, without changing busybox package? Mar 31 12:54:52 hrw: nice one Mar 31 12:55:07 slapin, AFAIK, no. Mar 31 12:55:48 slapin, At a minimum you would need to copy the busybox recipe into the overlay. Mar 31 12:57:00 and the ancillary files the recipe relies on. Mar 31 13:00:49 ACTION  Mar 31 13:01:13 hrw: what should I understand from such a license? http://people.dsv.su.se/~fk/beatrix_download.html Mar 31 13:01:28 may I try to commit a recipe? Mar 31 13:01:45 seems forbidden at first sight :/ Mar 31 13:02:28 Half the cross-sdk recipes inherit sdk twice? :/ Mar 31 13:02:40 the gcc directory is so depressing :( Mar 31 13:04:06 ant_work, I would suggest that writing a recipe, as long as no patches are required, would be ok - for personal use, as anyone building that recipe will be downloading it themselves. You shouldn't ship a binary version though. Mar 31 13:04:17 ant_work, and I'm not a lawyer... Mar 31 13:04:31 patches will be required for sure... Mar 31 13:04:56 Then, I'd probably contact them and see what they say. Mar 31 13:05:01 well, I can try to contact the author Mar 31 13:05:05 yep Mar 31 13:05:30 ant_work: I would not publish recipe even ;d Mar 31 13:05:49 hrw: I see... Mar 31 13:14:15 ok.... Mar 31 13:14:17 http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?id=f1bcec322799f46d752fb8f524284efe4fcf7de4 Mar 31 13:16:28 sakoman_, This ^^^ seems to result in an error when doing dhcp. Mar 31 13:17:50 hrw: any example offhand of a such non-redistributable recipe we have in OE? Mar 31 13:17:55 if Mar 31 13:18:33 no Mar 31 13:18:37 I'd like to show to the author it's just metadata (with LICENSE field) Mar 31 13:31:14 RP, agree with your gcc remarks, the reason i (hesitatedly) suggested a cleanup is e.g. the existence of the gcc-4.3.*/debian dirs that are not used at all Mar 31 13:31:41 eFfeM: those would be valid cleanups Mar 31 13:31:53 eFfeM: I think its the removing versions that makes some people nervous Mar 31 13:32:03 * eFfeM is not going to burn his fingers again in removing anything Mar 31 13:32:07 Having said that I just removed everything before 4.2 from Poky... Mar 31 13:32:42 RP, understood that, but that is where stable branches and rev control systems are for Mar 31 13:33:03 RP eFfeM, I guess if people want old versions arround, there should at least be a comment in the recipe explaining explicitly why that version is required... Mar 31 13:33:17 eFfeM: That issues isn't going to get a resolution and I'd hate it for the toolchain cleanups to depend on it Mar 31 13:33:21 * eFfeM feels that gcc 3, being from 2004, does not really belong in a dev head in 2010, but eFfeM seems to be alone there Mar 31 13:33:32 MWelchUK_work_: agree Mar 31 13:33:44 eFfeM: Not alone, I just understand why people need the old versions Mar 31 13:34:02 eFfeM: I did leave a 2005 CSL toolchain in poky as if I remove it, I break two machines :( Mar 31 13:34:23 RP: nokia tablets which no one use? Mar 31 13:34:32 hrw: right Mar 31 13:34:42 hrw: I haven't decided what to do with them yet ;-) Mar 31 13:34:52 RP, if it is clear that people still need it, fine, but to me it seems some things are just left because no-one bothers to even check if they are used Mar 31 13:35:04 RP: you maintain poky and you do not have 770 nor n800 so drop them from Poky Mar 31 13:35:20 hrw: I do have an 800 actually ;-) Mar 31 13:35:35 hrw: its even on the desk but not used in a while :/ Mar 31 13:35:36 if they are not actively maintained, i have doubts on keeping things around Mar 31 13:35:37 RP: you bought/got one? Mar 31 13:35:51 hrw: a long time ago, yes Mar 31 13:35:59 hrw: My dad has a 770 too... Mar 31 13:36:00 RP: as I remember that your n800dev had to go back Mar 31 13:36:27 hrw: this is a release device I bought with developer discount so its mine ;-) Mar 31 13:36:42 ok Mar 31 13:37:19 I was considering trying 2.6.34-rc2 on n810 but have other things to do Mar 31 13:38:00 hrw: The code for those machines in poky is rather old :( Mar 31 13:38:18 * RP will have to clean out the machines at some point Mar 31 13:38:34 RP: OE is not more fresh I think Mar 31 13:38:57 MWelchUK_work_: pump works better then dhcp-client for me here Mar 31 13:43:04 hrw: about stable/2009, please ack my patch about initramfs image. The second patch for zaurus updater would be also fine, though packaged-staging is broken in stable too... Mar 31 13:43:21 both from .dev Mar 31 13:43:34 ok, will take a look Mar 31 13:43:45 I plan some invasive changes for .dev Mar 31 13:45:31 it's better to let stable 'as it was' and make the jffs2 images compatible with Narcissus (e.g. no sharp headers) Mar 31 13:45:50 ubifs oneday, perhaps... Mar 31 13:47:45 MWelchUK_work_: please pull and rebase Mar 31 13:47:52 03Marcin Juszkiewicz  07org.openembedded.dev * rb762948c49 10openembedded.git/recipes/tasks/task-proper-tools.bb: Mar 31 13:47:52 task-proper-tools: added more applications Mar 31 13:47:52 Part of work was done by Martyn Welch, part by me. Mar 31 13:47:52 Signed-off-by: Marcin Juszkiewicz Mar 31 13:47:57 03Marcin Juszkiewicz  07org.openembedded.dev * r920132b42d 10openembedded.git/recipes/ifupdown/ (7 files in 2 dirs): Mar 31 13:47:57 ifupdown: update to 0.6.10 and do not ship /etc/network/interfaces Mar 31 13:47:57 Init script was renamed to ifup like it is in ifupdown-ubuntu Mar 31 13:47:57 Signed-off-by: Marcin Juszkiewicz Mar 31 13:48:17 hrw, fine with pump - as long as it works... Mar 31 13:48:38 MWelchUK_work_: it is very quiet by default also Mar 31 13:49:36 hi eFfeM, you're against old recipes, that's great,but what about compat distro? like sharprom-compat or maemos-compat? Mar 31 13:49:49 how are they handled? Mar 31 13:50:40 and how should they be handled? different branches? Mar 31 13:52:03 I guess there's an old vs. unreferenced issue here. Mar 31 13:54:05 hrw you've removed openrdate? Mar 31 13:55:04 I assume that ifupdown-ubuntu actually isn't needed? Mar 31 13:55:04 broonie: you are our audio master...is linux ready to have very low latencies? It's a bit I don't compare Asio vs. Jack Mar 31 13:56:46 MWelchUK_work_: I used ifupdown 0.6.10 on bug20 and it works Mar 31 13:56:54 MWelchUK_work_: sorry for openrdate - will add it Mar 31 13:57:15 MWelchUK_work_: I had 3 copies of that file Mar 31 13:57:38 MWelchUK_work_: openrdate is in task-proper-tools which I pushed Mar 31 13:58:01 ant_work: With suitable hardware combinations and configurations reasonably low latency should be achievable. Mar 31 13:58:54 ant_work: Not sure what asio is but jack is essentially a pro audio soft mixing/routing/algorithms stack (a bit like pulse but for higher end setups. Mar 31 13:59:01 Well, I dream about a midi controller like this: http://www.bgmi.it/?a=showproduct&b=1 Mar 31 13:59:06 There are a few others that I had in that you didn't include - I'll hold them in my patch for now - we wanted to replace all the functionality provided by the standard busybox build, just in case... Mar 31 13:59:16 broonie: this is the sound-core Mar 31 13:59:53 http://www.bgmi.it/?a=showproduct&b=2 Mar 31 14:00:08 is it safe to delete tmp/deploy/glibc/pstage ? or what is its content for ? Mar 31 14:00:46 ant_work: "sound-core"? Mar 31 14:00:49 broonie: instead of XP embedded, I'm hoping a quick arm + linux virtual instrument. But I fear about midi/audio Mar 31 14:00:50 * broonie -> meeting, back in an hour Mar 31 14:01:07 ant_work: People are doing pro audio systems based on Linux, and phones... Mar 31 14:01:24 so it's linux,. not QNx or such Mar 31 14:01:34 realtime OS Mar 31 14:02:31 rob_w: you see..this is the only dir to keep if you want to rebuild from packaged-staging :) Mar 31 14:02:33 some of the most expensive mixing desks run linux :D Mar 31 14:03:08 XorA: I had a short talk on #beagle and some said latency *is* an issue Mar 31 14:03:19 so if i want to form a image out of the packaged stuff .. Mar 31 14:04:36 ant_work, so normally if i kick to build a image i dont need it , right ? Mar 31 14:04:42 XorA: the hw they sell is not so special (for XP): ATOM cpu + Behringer audio card Mar 31 14:05:04 latency is always an issue, you need to be more specific Mar 31 14:05:29 XorA: you see, the original Hammond has NO latency at all (tonewheels are spinning) Mar 31 14:05:44 aso the phase of the sinusoids is the same Mar 31 14:06:09 if you introduce dekays (or use samples) you have phase-shift effects Mar 31 14:06:14 *delays Mar 31 14:06:15 ant_work: ah, yes, using digital instruments you need to remeber about the startup times Mar 31 14:06:50 ant_work: Cubase actually has the ability to delay channels to fix the latency, this obviously doesnt help if you play live Mar 31 14:07:13 btw I'm absolutely beginner with that keyboards :D Mar 31 14:07:32 I'm more a midi-player ;) Mar 31 14:08:07 same here :-D Mar 31 14:08:26 * XorA has a novation bass station, that is it Mar 31 14:10:44 I'll put back my rack of expanders the day my son will be able to understand they are not percussions :/ Mar 31 14:11:31 * mckoan ha s Novation Xio-49 :-D Mar 31 14:11:37 GNUtoo was afk, i feel that actively maintained distro's in dev should aim to use the latest versions of a recipe (unless there is a good reason not to, I can imagine for u-boot, kernel, gcc and a few other recipes there might be reasons. Old/legacy/unmaintained distro's probably should be in a stable or maintenance branch Mar 31 14:11:48 but that is my opinion, not of others Mar 31 14:12:28 ok Mar 31 14:13:36 so , what happens if i remove tmp/deploy/glibc/pstage/* ? Mar 31 14:13:52 mckoan: nice one, bad has not 61 keys Mar 31 14:14:45 rob_w: if you want to do a clean rebuild, wipe all in tmp Mar 31 14:14:45 i can imagine that some additional care is needed for recipes on which the build process heavily depends, but I really don't see the point of having multiple versions of abiword, or opie recipes for 1.2.2, 1.2.3 and 1.2.4 Mar 31 14:15:11 rob_w: if you let the pstage dir the rebuild will be faster Mar 31 14:15:15 again, my opinion, others thing differently Mar 31 14:15:25 eFfeM, ok Mar 31 14:15:33 i just want to get some space free and pstage holds all all those ipk`s again Mar 31 14:15:48 ant_work: when I need more keys I use my Yamaha P80 Mar 31 14:15:52 eFfeM, were should we document why old version are needed? Mar 31 14:15:58 k nevermind .. i dump it Mar 31 14:16:03 mckoan: bummer! Mar 31 14:16:08 :) Mar 31 14:16:14 ant_work: ;-) Mar 31 14:16:25 eFfeM, for instance there are 2 wesnoth version,the 1.4x could be needed for 320x240 screen size Mar 31 14:16:32 you see, I'm tempted to learn playing organ Mar 31 14:17:30 I bet there is no place to document that Mar 31 14:18:04 GNUtoo, don't know wesnoth; could imagine the 1.6.5 version could be made to support different res Mar 31 14:18:29 eFfeM, it can,but it would need some work,for instance modifying the themes files Mar 31 14:18:41 03Marcin Juszkiewicz  07org.openembedded.dev * rf0c802f046 10openembedded.git/recipes/ifupdown/ifupdown_0.6.10.bb: Mar 31 14:18:41 ifupdown: install init script as executable Mar 31 14:18:41 Signed-off-by: Marcin Juszkiewicz Mar 31 14:18:56 actually every once in a while I bump into an issue that I need a different kernel defconfig or some additional variants (eg for profiling) Mar 31 14:19:03 if this is done,it would need to be submited upstream Mar 31 14:19:34 GNUtoo if the 1.6 version does not do 320x240 and the 1.4 version does, that is a good reason to keep it around Mar 31 14:19:46 ok Mar 31 14:19:46 i have no problems in keeping versions around if there is a good reason for it Mar 31 14:19:53 mckoan: you too have realtime knowledge, do you think it is feasible to synch midi and audio with cheap hardware? Mar 31 14:19:57 but frankly speaking sometimes i think it is just lazyness Mar 31 14:20:03 for some recipes Mar 31 14:20:16 ok Mar 31 14:21:00 btw I can also understand that there are two (or more) variants of a recipe, eg like we have with opkg where there is a nocurl variant Mar 31 14:21:22 ~lart opkg/ipkg Mar 31 14:21:22 * ibot takes out a cattle prod and gives opkg/ipkg a good jolt Mar 31 14:21:52 eFfeM, I think we need to document what's needed and why,that could help us get rid of the rest Mar 31 14:22:09 e.g. now if want bluetooth you also get bt media profile (or whatever it is called) and include gstreamer, which is pretty pointless if all you want is use BT serial profile to connect to a GPS Mar 31 14:22:47 yes I understand that Mar 31 14:22:52 GNUtoo, tried to start that discussion a few times, but gave up, the force against it is too strong Mar 31 14:23:09 else all double recipes would be machine arch Mar 31 14:23:13 people coming with legacy distros or recipes unknown to oe Mar 31 14:23:25 ok Mar 31 14:23:41 could we make theses people document what is needed and why? Mar 31 14:23:52 I bet that's impossible Mar 31 14:24:50 ant_work: depends on what do you mean with "cheap hw", I know companies using ARM based boards to manage MIDI Mar 31 14:26:19 mckoan: http://www.bgmi.it/?a=showproduct&b=2 Mar 31 14:26:29 imagine to excange this Mar 31 14:28:56 GNUtoo :-) Mar 31 14:30:53 GNUtoo I'll happily go over the tree and remove dead recipes (where dead == not pinned by anyone and not latest) but got too much headwind Mar 31 14:31:06 indeed Mar 31 14:31:10 not a good idea Mar 31 14:31:13 this is still an agenda point for TSC Mar 31 14:31:19 ok Mar 31 14:31:29 if only for the 28 glib recipes Mar 31 14:31:35 keep in mind the idea of documenting why old recipes are needed Mar 31 14:31:39 anyway, I have up on this Mar 31 14:31:43 that could be usefull Mar 31 14:32:04 eFfeM: now that you mention it, I think there is a minor packaging issue with the last glib Mar 31 14:32:16 iirc a couple of dbg.py are not packaged Mar 31 14:32:21 another way to do it would be to put a warning Mar 31 14:32:28 like this file will be removed in 1 month Mar 31 14:32:39 in gentoo they hard mask the file Mar 31 14:32:52 and then after a time they remove it Mar 31 14:33:01 both ideas could be combined Mar 31 14:33:20 becuase removing things wihout a plan would not be good Mar 31 14:33:25 GNUtoo, there are several options possible, but apparently some people are so mordicus against it that I feel it is pointless to even try it Mar 31 14:33:29 GNUtoo: the point is someone outside in the wild could use a specific recipe w/out our knowledge. Sure they'll find all in the old branches Mar 31 14:33:38 eFfeM: ^ Mar 31 14:33:41 I know Mar 31 14:34:01 I wonder if theses people sync against .dev Mar 31 14:34:08 I doubt Mar 31 14:34:09 or how they work Mar 31 14:35:25 ant_work: I understand that but if you have a recipe unknown to OE (and yes, i have a few) then it is your problem not oe's problem Mar 31 14:35:47 submit them or create your own branch where you leave the versions that you need Mar 31 14:35:51 or put them in a local overlay Mar 31 14:36:04 I know only how buglabs work,they use an oe overlay but they use stable Mar 31 14:36:37 ask ubuntu if you can have gcc 3 in the feeds of 10.04 :-) Mar 31 14:36:59 ant_work: yes, would be possible Mar 31 14:37:02 anyway really need to go now probably online @home in a few hrs Mar 31 14:37:09 in that case they build against oe.stable and the overlay is their recipes Mar 31 14:37:21 so basically they keep their recipe in sync with oe.stable Mar 31 14:37:29 they also use jalimo Mar 31 14:37:33 mmm Mar 31 14:37:34 mckoan: great. In that case I can think about buying the chassis' Mar 31 14:37:57 the two waterfall manuals are tempting... Mar 31 14:37:59 and their recipes are public but not all in oe Mar 31 14:38:22 morning Mar 31 14:38:43 in that case if they sync,I bet they have to keep their recipes in sync with oe.stable Mar 31 14:38:52 and they sync Mar 31 14:39:12 in the case where a company doesn't sync,why bother? Mar 31 14:40:20 hi kergoth_ Mar 31 14:40:21 * kergoth_ thinks we need to somehow make it easier for companies to sync.. it's a pain, involving manual work, every time, today Mar 31 14:41:01 kergoth_: The main reason - why do people need to change OE? Mar 31 14:41:02 ok,how should we do that? Mar 31 14:41:04 RP: last night I noticed that the initial bitbake parse time was about 4 times slower than 1.8.. changing the anonfuncs to not use exec_func brought it back to 1.8 levels -- i suspect the python function logging bits Mar 31 14:41:41 just as an fyi :) Mar 31 14:41:57 kergoth_: Can you show me the patch you used please? Mar 31 14:41:57 btw sho is involved in security and know well openssl and has some little time Mar 31 14:41:58 ? Mar 31 14:42:14 RP: I can add that the (now disappeared) 1.10 was indeed faster parsing and building the runqueue Mar 31 14:42:29 RP: it's on the head of master, I changed all exec/eval to use utility functions in bb.utils, with the context stored there Mar 31 14:42:31 hrw, I get a missing checksum on ifupdown-0.6.10 Mar 31 14:42:40 ant_work: It should be the same as master. If its not, we should fix that Mar 31 14:42:47 RP: can always revert if it causes problems, but i have builds going, seems functional Mar 31 14:42:54 shit Mar 31 14:43:08 oh, I'm still on 1.8.18, master had some nasty python issues last time I tried Mar 31 14:43:46 JaMa: should remember better Mar 31 14:44:42 hrw, http://pastebin.com/4EAUiSN9 Mar 31 14:45:11 ant_work: please test master if you have a chance, we'd like to get any remaining issues fixed so we can get a release out at some point Mar 31 14:45:12 thx Mar 31 14:45:25 kergoth: sure Mar 31 14:46:23 ant_work: We fixed Jama's issues Mar 31 14:46:59 great to hear Mar 31 14:47:14 kergoth_: Does this go back to executing each anonymous function in turn? Mar 31 14:47:19 it was some math function iirc Mar 31 14:47:39 RP: for now, can easily change it back, was busy trying to get it to stop exploding Mar 31 14:47:55 there were some assumptions made in various places about things being global rather than local Mar 31 14:48:21 03Martyn Welch  07org.openembedded.dev * re398449f66 10openembedded.git/recipes/ifupdown/ifupdown_0.6.10.bb: Mar 31 14:48:21 ifupdown: added checksums Mar 31 14:48:21 Signed-off-by: Marcin Juszkiewicz Mar 31 14:48:29 kergoth_: :( Mar 31 14:48:37 hrw, Think this might fix the hwclock error at boot: http://pastebin.com/xbuhGh3k Mar 31 14:48:41 RP: well, i prefer 1m30s to 5m parse time. Mar 31 14:48:47 maybe we can speed it up past that, sure Mar 31 14:49:32 kergoth_: You've merged several different problems here :/ Mar 31 14:50:20 there's no reason they need to all run in their own little worlds, and the __builtins__ is no longer necessary. Mar 31 14:50:28 the methodpool injects into the shared global context now Mar 31 14:50:50 kergoth_: if that were true, the combined function thing would still be working Mar 31 14:50:55 huh? Mar 31 14:51:19 making anonfuncs run as one exec again is about 2 minutes of work Mar 31 14:51:20 probably less Mar 31 14:51:59 kergoth_: you just said above it had to be removed due to assumptions made in various places about things being global rather than local? Mar 31 14:52:06 what? Mar 31 14:52:10 no Mar 31 14:52:24 those assumptions are why i had to spend so much time getting it to stop shitting itself Mar 31 14:52:35 now i can spend a small amount of time tweaking further Mar 31 14:53:04 I guess I don't understand why the common function thing was removed if it wasn't the problem Mar 31 14:53:19 anyhow, lets see if we can really find out what caused the slowdown Mar 31 14:53:42 What part of "i was making it stop exploding" fails to sink in? Mar 31 14:54:17 And if you'd bothered to read the patch, you'd have seen that its not a problem to add it Mar 31 14:54:35 MWelchUK_work_: does it works with busybox? Mar 31 14:54:54 kergoth_: obviously I'm just too think to understand this Mar 31 14:55:13 hrw, it seems to on BusyBox v1.13.2 Mar 31 14:55:32 Though my local time zone currently is utc :-) Mar 31 14:56:17 and it errors if I try "hwclock --defnotthere" Mar 31 14:58:21 kergoth_: "trying to stop it exploding" does not give me any information about how it was exploding. I can guess it may have involved the merged function somehow but I'm not physic so I can't know how. This is why I'm asking Mar 31 14:58:39 RP: I recall now why I did it this way to get it working. To utilize better_exec requires the text of the function and the filename, neither of which are available given the information stored in anonfuncs Mar 31 14:59:13 so I did it this way for the time being, figured we could go back and either add a basic_exec or add more info to the anonfuncs. Mar 31 14:59:29 kergoth_: Thanks. That reply is a bit more helpful :) Mar 31 14:59:30 so there's your answer. i did it to get the fucking thing to work, like i said Mar 31 15:00:12 kergoth_: Asking why is a valid question and its not becuase I'm not reading the patch ;-) Mar 31 15:00:15 Ideally, we'd do it so you get usable errors when an anonfunc fails Mar 31 15:00:23 but the way we were doing it before, that wasn't the case Mar 31 15:01:03 of course, ideally we'd have usable errors in all exec/eval's, but we don't have enough information in either expand() or bb.event today Mar 31 15:01:14 if you know how the function name is contructed you can work back to find it but I agree its not ideal Mar 31 15:02:01 kergoth_: Another part of the aim of that code was to get meaningful error logs on python failures Mar 31 15:02:16 A 4 times parsing slowdown is not acceptable of course Mar 31 15:02:26 the odd thing is I don't see that in Poky :/ Mar 31 15:02:40 or I can make poky 4 times faster which would be impressive Mar 31 15:03:36 I suspect you can bring back the slowdown by making it use exec_func again. there's no need for it to do so though, its not a function, or a task, its just exec_func was our only python code execution tool at that time, its a remnant from early days Mar 31 15:04:12 exec_func is a wrapper around better_exec with logging? Mar 31 15:04:35 If exec_func is really that slow I'd like to understand why Mar 31 15:04:55 agreed Mar 31 15:11:28 * kergoth_ tests merged anonfunc execution Mar 31 15:25:55 ant_work: Latency is going to be non-zero but there's no intrinsic problem with Linux that doesn't exist with any other OS. Mar 31 15:28:13 hrw, ifupdown is failing to create "${mandir}/man8" Mar 31 15:28:35 moment Mar 31 15:29:28 hrw, I added "install -d ${mandir}", which also failed as /usr/share doesn't exist? Mar 31 15:29:56 03Marcin Juszkiewicz  07org.openembedded.dev * re2331268d0 10openembedded.git/recipes/ifupdown/ifupdown_0.6.10.bb: Mar 31 15:29:56 ifupdown: fix do_install Mar 31 15:29:56 Signed-off-by: Marcin Juszkiewicz Mar 31 15:30:15 hrw, Ah :-) Mar 31 15:30:57 RP: seems like precompiling the objects at parse time gets you about 90% of the improvement that merging gets you, without confusing the error output. still playing around, will see Mar 31 15:31:13 * kergoth_ experiments Mar 31 15:31:26 hey Crofton Mar 31 15:32:09 hey Mar 31 15:41:00 * kergoth grumbles Mar 31 15:41:39 bye all Mar 31 15:41:58 hrw, s'later Mar 31 15:42:03 MWelchUK_work_: I got devs to test results of our work on devices ;D Mar 31 15:42:47 * MWelchUK_work_ just has himself. Mar 31 15:47:12 hmm, looks like a compiled code object retains its knowledge of the filename, should be able to make that optional for better_exec if it's one Mar 31 15:57:41 wonder how much work it'd take to get the line numbers in python exec errors adjusted to be real line numbers in the files.. probably just need to compile at ast time where possible and pass around the lineno field as the starting line number Mar 31 15:58:16 sadly, code object's co_firstlineno field is read only.. heh Mar 31 16:02:51 pb_: Mar 31 16:03:04 NOTE: Running task 469 of 475 (ID: 14, /local/pkg/oe/openembedded/recipes/linux/linux-leviathan_git.bb, do_package) Mar 31 16:03:04 sh: arm-oe-linux-gnueabi-depmod-2.6: command not found Mar 31 16:03:13 could that be responsible for the broken module depends atm.? Mar 31 16:08:48 Crofton: ping Mar 31 16:09:04 pong Mar 31 16:09:15 Crofton: hi. ka6sox needs your ssh key Mar 31 16:09:19 k Mar 31 16:09:24 you have his email? Mar 31 16:09:41 can you send it to me Mar 31 16:09:44 his nickname @ gmail.com Mar 31 16:09:50 thanks Mar 31 16:12:09 kergoth_: Did you see that function name mangling function? Mar 31 16:12:31 kergoth_: for anonymous methods - that included the line number in the function name Mar 31 16:12:33 function name mangling function? you mean the fn.translate() used for the anonfuncs? Mar 31 16:12:36 yes, i know Mar 31 16:12:56 kergoth_: I had wondered about parsing the tracebacks and using that to offset the line numbers Mar 31 16:13:56 sounds pretty hackish, would think it would be better to pass the starting lineno to the better_* functions the way realfile is Mar 31 16:14:14 kergoth_: yes, that would be better :) Mar 31 16:14:44 just pushed a resurrection of the merged anonfuncs, for the time being. still looking into the alternative though Mar 31 16:15:07 merged is now cutting the time from 1m21s to 1m20s, roughly Mar 31 16:15:58 kergoth: The reason I added that code was that the previous version was using all the concatenated python which broken on the whitespace Mar 31 16:16:29 yeah, this is obviously an improvement, using a function for each anonfunc Mar 31 16:16:37 kergoth_: I also wanted the methodpool to start being useful and avoid recompiling functions all the time Mar 31 16:18:21 regardless, the intent of the patch was to consolidate the eval/exec bits, the performance change and merge/not merge was incidental Mar 31 16:18:33 * kergoth gets caffeine Mar 31 16:19:00 kergoth_: I know, its all a balancing act Mar 31 16:19:25 we need to find a way to make this less brittle. it'd help if we had real unit and performance tests to catch regressions :\ Mar 31 16:19:59 kergoth: Yes, it would help. Using OE/Poky as a testsuite is less than ideal Mar 31 16:47:02 03Michael 'Mickey' Lauer  07org.openembedded.dev * re36460c470 10openembedded.git/recipes/linux/ (linux-leviathan/defconfig linux-leviathan_git.bb): Mar 31 16:47:02 linux-leviathan: fix suspend/resume Mar 31 16:47:02 Note to self: hand-editing defconfig and multistate configs doesn't match Mar 31 16:47:31 kergoth: 'bitbake -p console image' takes: Mar 31 16:47:43 with 1.8.18 real 3m51s Mar 31 16:48:26 testing master Mar 31 16:48:56 :) 2m33s Mar 31 16:56:57 Has anyone ever dealt with taking SRPM sources and cross-compiling them as well as utilizing the cross-compiled binary RPM in a staging directory? Mar 31 16:57:55 Converting an SRPM + spec to OE recipes isn't hard, manually Mar 31 16:58:02 So long as you speak both :) Mar 31 16:59:39 I noticed an old version of libaio was doing just that and using the rpm_core and base_srpm classes to build the SRPM, but they manually did a staging task to explicitly install develpment headers and libraries. Would it be possible to just plain install the RPM into the staging directory, maybe an additional rpm2cpio command for the do_staging task? Mar 31 17:01:12 Ah, I've not played with that stuff before Mar 31 17:01:43 So that's a different thing Mar 31 17:02:09 The problem with re-using binary RPMs is that we don't know that they will be compatible with what we build Mar 31 17:02:28 One could make a new distro conf and do things to ensure that it worked Mar 31 17:02:53 I think there's an example or two in OE now of compatible with ____ external distribtuions Mar 31 17:03:17 And I'm pretty sure that there's companies somewhere that have taken $ and wrapped OE around it Mar 31 17:35:57 Yeah, that is basically what I would like to do ;) Mar 31 17:37:50 any Bitbake DSL experts in the house? Mar 31 17:38:58 I have a bbclass that has some Python functions and I'd like to expand some data from the datastore and save them as variables with class scope Mar 31 17:39:09 can anyone point me at how to do that? Mar 31 17:39:11 covalence: Well, it can done, yes :) It takes time tho Mar 31 17:42:53 Tartarus: Yeah...I am finding that out now ;) Mar 31 17:46:27 incandescant: bb.data.setVar() to set variables, bb.data.getVar() to get them. if you want to adjust the metadata with python, create a python function with no name (anonymous), those are run at the end of the recipe parsing process, so you can use them to make adjustments to the metadata. see the bbclasses, they're used in a number of places, including base.bbclass Mar 31 17:48:06 incandescant: an alternative for setting just one variable with python would be to 'def' a python function and call it from the variable. FOO = "${@myfunc(d)}" Mar 31 17:48:37 kergoth_: thanks :-) Mar 31 17:53:23 incandescant: np Mar 31 17:54:59 incandescant: also note that currently classes that are inherited by 'inherit' rather than INHERIT (which end up in the configuration metadata) are essentially injected at that exact point into the recipe metadata. it doesn't remain separate, so there is no "class scope" at the moment. I'd like to change that, moving those classes into a layer between the config metadata and the recipe, but that's not how it happens tdoay Mar 31 17:55:06 s/tdoay/today/ Mar 31 17:55:52 kergoth_: I inferred as much from your response, but thanks for clarifying! Mar 31 17:56:02 kergoth_: I can certainly see a use to a class scope Mar 31 17:58:39 there's a bit of confusion in our format, some things feel imperative, others feel declarative. the immediate operation of inherit is one of those, in my opinion Mar 31 18:25:07 re Mar 31 18:33:29 hi, is git working? Mar 31 18:39:58 ka6sox: just git pulled successfully Mar 31 18:57:32 JaMa, thanks. Mar 31 19:00:24 ka6sox, you need a key? Mar 31 19:01:20 03Roman I Khimov  07org.openembedded.dev * rb055e9c76e 10openembedded.git/recipes/postfix/ (postfix.inc postfix_2.0.20.bb postfix_2.2.12.bb): Mar 31 19:01:20 postfix: convert to INC_PR Mar 31 19:01:20 Signed-off-by: Roman I Khimov Mar 31 19:01:20 03Roman I Khimov  07org.openembedded.dev * rd7ff8f75b3 10openembedded.git/recipes/spamassassin/ (11 files in 2 dirs): (log message trimmed) Mar 31 19:01:20 spamassassin: new recipe Mar 31 19:01:21 SpamAssassin is a very powerful and fully configurable spam filter with Mar 31 19:01:22 numerous features including automatic white-listing, RBL testing, Bayesian Mar 31 19:01:22 analysis, header and body text analysis. It is designed to be called from Mar 31 19:01:23 a user's .procmail or .forward file, but can also be integrated into a Mar 31 19:01:23 Mail Transport Agent (MTA). Mar 31 19:01:31 03Roman I Khimov  07org.openembedded.dev * rd378fb6c96 10openembedded.git/recipes/update-rc.d/update-rc.d_0.7.bb: Mar 31 19:01:32 update-rc.d: allow native build via BBCLASSEXTEND Mar 31 19:01:32 Makes it possible to use BBCLASSEXTEND for native in packages inheriting Mar 31 19:01:32 update-rc.d. Mar 31 19:01:32 Signed-off-by: Roman I Khimov Mar 31 19:02:28 03Koen Kooi  07org.openembedded.dev * r29dc4e1f84 10openembedded.git/recipes/gnome/system-tools-backends_2.8.3.bb: system-tools-backends 2.8.3: reinstate policykit support Mar 31 19:19:49 03Martin Jansa  07org.openembedded.dev * r270bd65066 10openembedded.git/recipes/shr/ (phoneui-shr-theme-neo_git.bb phoneui-shr-theme-o2_git.bb): phoneui-shr-theme: bump SRCREV for o2 and neo theme Mar 31 20:19:20 03Martin Jansa  07org.openembedded.dev * r8c1753f14b 10openembedded.git/recipes/linux/ (2 files in 2 dirs): Mar 31 20:19:20 linux-openmoko-2.6.32: update defconfig, add BT support, more watchdogs Mar 31 20:19:20 Signed-off-by: Martin Jansa Mar 31 20:33:14 mickeyl: good evening Mar 31 20:52:17 03Adrian Alonso  07org.openembedded.dev * r26aa41630f 10openembedded.git/recipes/imagemagick/ (files/openm4-autoconf-fix.patch imagemagick_6.3.5-10.bb): (log message trimmed) Mar 31 20:52:17 imagemagick_6.3.5-10.bb: openm4 fix Mar 31 20:52:17 * m4/openmp.m4 (AC_OPENMP): Do not define with Autoconf 2.62 or newer. Mar 31 20:52:17 2008-12-03 Ralf Wildenhues <[EMAIL PROTECTED]> Mar 31 20:52:17 Bruno Haible <[EMAIL PROTECTED]> Mar 31 20:52:18 * ref: http://www.mail-archive.com/bug-gnulib@gnu.org/msg12387.html Mar 31 20:52:19 Signed-off-by: Adrian Alonso Mar 31 21:30:17 pb_: hi pb_ Mar 31 21:30:30 NOTE: Running task 469 of 475 (ID: 14, /local/pkg/oe/openembedded/recipes/linux/linux-leviathan_git.bb, do_package) Mar 31 21:30:30 sh: arm-oe-linux-gnueabi-depmod-2.6: command not found Mar 31 21:30:30 could that be responsible for the broken module depends atm.? Mar 31 22:55:56 03Khem Raj  07org.openembedded.dev * rcd25de5ea0 10openembedded.git/recipes/eglibc/ (eglibc_2.10.bb eglibc_2.11.bb eglibc_2.9.bb eglibc_svn.bb): Mar 31 22:55:56 eglibc: Apply branch fixes. Mar 31 22:55:56 * Use the latest tip of the respective branches Mar 31 22:55:56 which have received bug fixes. Mar 31 22:55:56 * Move svn recipe to latest. Mar 31 22:55:57 Signed-off-by: Khem Raj Mar 31 23:48:24 mickeyl, hi, you around ? Mar 31 23:49:08 ya Apr 01 00:25:58 Hi all, I built OE for dm6446 and use montavista kernel 2.6.18. Both kernel and filesystem works well as I expected. But, I've got one problem, the architecture written on .pkg file was armv5te while uname was returning armv5tejl. Anyone know how to fix it? Apr 01 00:41:10 mickeyl, sorry for the delay ... don't you know what nick does Rolf have ? Apr 01 00:41:54 laibsch Apr 01 01:01:24 ~seen laibsch Apr 01 01:01:26 laibsch <~Laibsch@p5B3B3ED8.dip.t-dialin.net> was last seen on IRC in channel #oe, 6d 10h 1m 5s ago, saying: 'JaMa: logs are expired after 3 months anyhow'. Apr 01 01:01:37 mickeyl, thanks **** ENDING LOGGING AT Thu Apr 01 02:59:57 2010