**** BEGIN LOGGING AT Thu Nov 19 02:59:57 2009 Nov 19 04:19:00 * kergoth twitches Nov 19 04:53:02 Does anyone see an Auto-Installed field in their 'opkg status' output? Nov 19 04:53:38 Surely this would be common, but I can't see any pacakges marked as auto installed Nov 19 04:53:52 --opkg_credibility Nov 19 04:55:30 no wonder the orphan dependency removal code can exist with so many bugs... Nov 19 04:55:43 its never executed Nov 19 05:05:22 Is opkg documented? Nov 19 05:06:10 I mean, in a form that general users and distro developers would find useful so they would know about the features and expected behaviors (use cases, scenarios, examples)? Nov 19 05:07:05 I know that with SlugOS I stick to the narrow set of stuff that I have used in the past and know to work; straying from that seems risky. :) Nov 19 05:09:43 i have seen no documentation beyond the code Nov 19 05:10:12 i've been looking at the debian policy manual for some bits Nov 19 05:11:37 i've actually only learnt of features from code inspection. there's plenty in the help output that is just confusing Nov 19 05:11:56 and stuff that's not in the help output at all Nov 19 05:13:21 btw, mwester, i merged some of your patches in. Nov 19 05:13:37 oooh! cool. Nov 19 05:13:46 and probably made the others not apply :P Nov 19 05:13:55 Yeah, well, that's to be expected. Nov 19 05:14:31 I'd be happy to have them all merged in; which one(s) didn't make it? Nov 19 05:16:09 the vfork_gunzip patch Nov 19 05:16:22 and the slugos specific path changes Nov 19 05:16:49 As long as there are no fork() calls left, the gunzip stuff is no problem. Nov 19 05:17:08 opkg still forks for the unzip code Nov 19 05:17:16 Ok, then it will still crash. Nov 19 05:17:34 i'm holding off on that until i can comfortably update libbb Nov 19 05:18:36 As long as we can agree that the use of fork() (and things that use fork(), like system()) need to be expunged from opkg, so that we can avoid the evil eye of the OOM Killer. Nov 19 05:18:51 oh yes Nov 19 05:18:56 system() is gone Nov 19 05:19:09 rm -fr is now a proper c function Nov 19 05:19:24 all the temp files should be limited to their own directory Nov 19 05:19:36 /tmp? Nov 19 05:19:40 by default Nov 19 05:19:59 a dir off /tmp/opkg-XXXXXX Nov 19 05:19:59 Ah. I'd love to see that location be read from the config file. :) Nov 19 05:21:02 yes, that should be trivial Nov 19 05:21:21 I'll add a task to my to-do list to fetch the latest opkg and see how it works on the NSLU2 :) Nov 19 05:21:31 not sure why its not there already. the temp dir arg is Nov 19 05:21:43 If you're putting all that effort in, the least I should do is use it! :D Nov 19 05:22:00 thank you. I would like lots more testing Nov 19 05:22:11 i'm sure i'm breaking something Nov 19 05:22:29 hehe! Can't be worse than it was, and it sounds like it's better. Nov 19 07:41:27 good morning Nov 19 07:52:03 03Martin Jansa  07org.openembedded.dev * rcaad8440ff 10openembedded.git/recipes/mplayer/ (mplayer-common.bb mplayer-common/om-gta02/mplayer.conf): Nov 19 07:52:03 mplayer-common: add SHR specific config file Nov 19 07:52:03 Signed-off-by: Martin Jansa Nov 19 07:52:03 03Martin Jansa  07org.openembedded.dev * r2a12f6a75d 10openembedded.git/recipes/ (3 files in 2 dirs): Nov 19 07:52:05 task-fso* compliance: update requirements and include it in shr-image Nov 19 07:52:07 Signed-off-by: Martin Jansa Nov 19 07:52:09 03Martin Jansa  07org.openembedded.dev * r6225781142 10openembedded.git/recipes/efl1/elementary_svn.bb: Nov 19 07:52:13 elementary: don't pull elementary-tests by default Nov 19 07:52:14 Signed-off-by: Martin Jansa Nov 19 07:52:16 03Martin Jansa  07org.openembedded.dev * r887aca221e 10openembedded.git/recipes/ffmpeg/ffmpeg_svn.bb: Nov 19 07:52:33 ffmpeg_svn: increase preference for shr Nov 19 07:52:33 Signed-off-by: Martin Jansa Nov 19 07:52:33 03Martin Jansa  07org.openembedded.dev * r8c855584e3 10openembedded.git/recipes/alsa/alsa-state.bb: Nov 19 07:52:33 alsa-state: use virtual/alsa-scenarios Nov 19 07:52:33 Signed-off-by: Martin Jansa Nov 19 07:52:35 03Martin Jansa  07org.openembedded.dev * r6483ed351e 10openembedded.git/recipes/freesmartphone/ (fsodeviced/fsodeviced fsodeviced_git.bb): Nov 19 07:52:37 fsodeviced: update recipe from SHR Nov 19 07:52:39 Signed-off-by: Martin Jansa Nov 19 07:52:41 03Martin Jansa  07org.openembedded.dev * r00a7b8623d 10openembedded.git/recipes/openmoko-projects/paroli_git.bb: Nov 19 07:52:46 paroli: updated recipe from Angus Nov 19 07:52:48 Signed-off-by: Martin Jansa Nov 19 07:52:50 03Martin Jansa  07org.openembedded.dev * re9b66bf6a4 10openembedded.git/recipes/bluez/bluez4_4.56.bb: Nov 19 07:52:53 bluez4: increase preference for shr, enable udevrules Nov 19 07:52:55 Signed-off-by: Martin Jansa Nov 19 07:52:59 03Martin Jansa  07org.openembedded.dev * r81f27f67f4 10openembedded.git/recipes/tangogps/tangogps.inc: Nov 19 07:53:04 tangogps: RRECOMMENDS fso-gpsd for SHR Nov 19 07:53:06 Signed-off-by: Martin Jansa Nov 19 07:53:08 03Martin Jansa  07org.openembedded.dev * r0f16423ff6 10openembedded.git/recipes/samsung-soc-utils/sjf2410-linux-native_svn.bb: Nov 19 07:53:11 samsung-soc-util: switch from https to http as certificat is not valid Nov 19 07:53:13 Signed-off-by: Martin Jansa Nov 19 07:53:17 03Martin Jansa  07org.openembedded.dev * ra7a02936e7 10openembedded.git/recipes/python/python-dbus_0.83.0.bb: Nov 19 07:53:22 python-dbus: add python-epydoc-native for buildhosts without epydoc Nov 19 07:53:24 Signed-off-by: Martin Jansa Nov 19 07:53:26 03Martin Jansa  07org.openembedded.dev * ra070023d0d 10openembedded.git/recipes/python/python_2.6.2.bb: Nov 19 07:53:29 (2 lines omitted) Nov 19 07:55:21 03Martin Jansa  07org.openembedded.dev * rea85d940c7 10openembedded.git/recipes/opensync/libsyncml_0.5.4.bb: Nov 19 07:55:21 libsyncml: add version 0.5.4 from SHR Nov 19 07:55:21 Signed-off-by: Martin Jansa Nov 19 07:55:21 03Martin Jansa  07org.openembedded.dev * r5049a1fcc4 10openembedded.git/recipes/opensync/wbxml2_0.10.7.bb: Nov 19 07:55:24 wbxml2: add version 0.10.7 from SHR Nov 19 07:55:27 Signed-off-by: Martin Jansa Nov 19 07:56:28 03Martin Jansa  07org.openembedded.dev * rf0dcb130e3 10openembedded.git/recipes/pidgin/msn-pecan_git.bb: Nov 19 07:56:28 msn-pecan: new recipe from SHR Nov 19 07:56:28 Signed-off-by: Martin Jansa Nov 19 07:59:39 03Tom  07org.openembedded.dev * r64931fdf4e 10openembedded.git/recipes/shr/libphone-ui-shr_git.bb: Nov 19 07:59:39 libphone-ui-shr's recipe now includes only relevant module files Nov 19 07:59:39 Signed-off-by: Martin Jansa Nov 19 08:15:13 03Thomas Zimmermann  07org.openembedded.dev * r26bb9d7130 10openembedded.git/recipes/mplayer/ (mplayer-0.0+1.0rc2/ivtv-fix.patch mplayer_0.0+1.0rc2.bb): Nov 19 08:15:13 shr/merge: mplayer: fix ivtv build problem Nov 19 08:15:13 Signed-off-by: Klaus Kurzmann Nov 19 08:56:50 good morning: today is qt 4.6 day Nov 19 08:57:06 * * OE Bug 5337 has been created by d.venzano(AT)motronica.com Nov 19 08:57:08 * * Error unpacking ../../openembedded/recipes/linux/linux-omap-2.6-2.6.9-omap1/defconfig Nov 19 08:57:11 * * http://bugs.openembedded.org/show_bug.cgi?id=5337 Nov 19 09:02:42 morning Nov 19 09:02:45 recalcati: release? Nov 19 09:03:20 commit 89ccbd14fe8c0e6b0fefcca2151da28d98088bf5 Nov 19 09:03:31 from 4.6 stable branch Nov 19 09:04:13 I made a bz2, I change script, I obtain, http://pastebin.com/f6dc9bb3c Nov 19 09:04:36 morning all Nov 19 09:04:47 I think that staging is not re-triggered in order to obtain qmake2 Nov 19 09:05:01 hi mckoan : now I can? Nov 19 09:05:37 recalcati: yes you can :-D Nov 19 09:05:43 ok Nov 19 09:15:49 03Sebastian Spaeth  07org.openembedded.dev * rb31701d667 10openembedded.git/recipes/tasks/task-fso2-compliance.bb: Nov 19 09:15:49 task-fso2-compliance: add tzdata back to RRECOMMENDS Nov 19 09:15:49 Signed-off-by: Sebastian Spaeth Nov 19 09:21:37 hmm, is the concept of /etc/rc.local not present in angstrom? Nov 19 09:25:06 03Sebastian Spaeth  07org.openembedded.dev * r3a2a7101e3 10openembedded.git/recipes/freesmartphone/fsodeviced/fsodeviced: Nov 19 09:25:06 fsodeviced: nice -19 by default in init script Nov 19 09:25:06 Signed-off-by: Sebastian Spaeth Nov 19 09:29:56 03Sebastian Spaeth  07org.openembedded.dev * r98025ddf1b 10openembedded.git/recipes/tasks/task-shr-minimal.bb: Nov 19 09:29:56 task-shr-minimal: pull in libcanberra-alsa for now until fsodeviced does it properly Nov 19 09:29:56 Signed-off-by: Sebastian Spaeth Nov 19 09:30:36 tzanger: thats not Debian style Nov 19 09:33:30 hrw: rc.local is in debian Nov 19 09:34:16 o.. it was not there when last checked (years ago) Nov 19 09:34:35 I just have /etc/init.d/hrw-* scripts symlinked to proper places Nov 19 09:34:40 hrw: create it and it shall run, but there is no default one Nov 19 09:35:00 hrw: check /etc/init.d/rc.local Nov 19 09:35:18 XorA: but not on angstrom? Nov 19 09:35:29 grepping for rc.local to see if anything rusn it doesn't seem to turn up any suspects Nov 19 09:35:57 tzanger: doesnt seem so Nov 19 09:36:12 tzanger: I dont think anyone would object to a patch Nov 19 09:38:14 *nods* Nov 19 09:38:41 right now I'm trying to figure out why ./myprog & doesn't background unless I do it interactively Nov 19 09:39:24 03Sebastian Spaeth  07org.openembedded.dev * r4a87c92ffb 10openembedded.git/recipes/tasks/task-shr-minimal.bb: Nov 19 09:39:24 task-shr-minimal: move comment above pkg listing. borked parsing. Nov 19 09:39:24 Signed-off-by: Sebastian Spaeth Nov 19 09:42:44 florian: good morning Nov 19 09:45:47 good morning Nov 19 09:47:21 recalcati: the best way to contribute to OE activities and giving visibility to your company would be a sponsorship http://wiki.openembedded.net/index.php/Become_Sponsor Nov 19 09:48:05 mckoan: I have to search money ... :-) Nov 19 09:48:09 thx Nov 19 09:48:30 recalcati: I could explain it better once we meet next month Nov 19 09:48:44 its ok Nov 19 09:49:04 pb__: EHLO Nov 19 09:49:21 hi ant_work Nov 19 09:49:23 * pb__ heads to the office now Nov 19 09:49:24 bbiab Nov 19 10:24:52 Currently im getting 100% of processor 1(/2), so total 50% system load. Any way to send more into the bitbake process? Nov 19 10:26:00 kristoffer: set PARALLEL_MAKE, and/or BB_NUMBER_THREADS Nov 19 10:26:14 inside local.conf? Nov 19 10:26:19 yes Nov 19 10:26:19 yes Nov 19 10:26:30 oki, thx Nov 19 10:26:35 kristoffer: http://marcin.juszkiewicz.com.pl/2008/04/07/speeding-up-bitbake-builds/ Nov 19 10:28:42 pb_: have you read our question about ioctl's of yesterday night? Nov 19 10:32:13 ant_work: no, what was that? Nov 19 10:35:15 pb_: was about optimal way to get mtd size Nov 19 10:35:44 what is heavier - ioctl(fd, BLKGETSIZE, ... ) on mtdblock or lseek(fd, 0, SEEK_END) on mtd? :) Nov 19 10:35:46 [20091119 00:39:59] or MEMGETINFO ( u_long size; /* Size of the device in bytes */ ) on mtd Nov 19 10:36:51 pb_: we decided to stay away from mtdblock Nov 19 10:37:03 atm we use lseek Nov 19 10:37:52 I doubt it makes any difference. Nov 19 10:38:05 presumably you're only doing this once, and any of those ioctls should be plenty fast enough. Nov 19 10:38:12 ant_work: what about parsing /proc/mtd contents? Nov 19 10:38:14 http://lnk.nu/git.linuxtogo.org/12tg/ Nov 19 10:38:40 Jay7 worked till 4'o clock last night. We finished :) Nov 19 10:39:04 actually it shouldn't make any bigg diff Nov 19 10:39:15 at least I didn't perceive any Nov 19 10:41:26 hrw: we don't trust the kernel (mtdparts set in the sources). We just need the sum of the sizes. This can be trusted. Nov 19 10:42:15 ant_work: /proc/mtd give you size of flash Nov 19 10:52:59 Ive created a new machine file and made some minor changes to distro file. My issue is that it tries to grab the wrong kernel source even though I specify PREFERRED_PROVIDER_virtual/kernel = .. Ive touched local.conf/distrofile/machine files and even removed the entire tmp folder and it still complains about multiple kernel files being available (and the correct one isnt among those). Any hints on what to bugsearch on? Nov 19 10:57:58 show machine config? Nov 19 11:17:26 raster: moin moin Nov 19 11:18:55 hi zecke Nov 19 11:26:19 hi mickey|sofa Nov 19 11:30:16 hi Nov 19 11:31:26 mickey|munichHBF: hey! Nov 19 11:31:38 mickey|munichHBF: I might not be in frankfurt for long on sunday.. Nov 19 11:33:03 morning all Nov 19 11:35:07 zecke: ok, just a short coffee will do, would just love to say i Nov 19 11:35:09 err Nov 19 11:35:11 hi, that is Nov 19 11:36:25 i can't walk much though Nov 19 11:36:34 have a serious injury in my left foot *sigh* Nov 19 11:36:56 mickey|munichHBF: :( Nov 19 11:37:28 mickey|munichHBF: yeah, I need to be back to frankfurt... so a coffee on tuesday night would rock (maybe even providing shelter as my flight is on wednesday) Nov 19 11:37:49 mickey|munichHBF: doh, what did you do to your foot? Nov 19 11:38:00 zecke: ok, sounds good. just tell me when you are where and i'll pick you up Nov 19 11:38:20 mickey|munichHBF: last sunday... there was some kind of health angel's meeting in the redlight district (next to my hotel)... and on my flight to Copenhagen there were like 6 really heavy angels on board too *scary* Nov 19 11:38:37 mickey|munichHBF: injury... did you get it while playing table tennis? Nov 19 11:39:20 pb_: apparantly i sprained it some weeks ago during sports (squash) but didn't notice. after returning from cambridge i could not walk at all anymore, since it was swollen. went to the doc and he said one of the bones is (not broken *phew*), but seriously stressed :/ Nov 19 11:39:43 mickey|munichHBF: argh :( Nov 19 11:39:58 mickey|munichHBF: crumbs, sorry to hear that. hope it heals soon. Nov 19 11:40:02 thanks Nov 19 11:40:03 my fantastique recipe for qt 4.6 doesn't see #include inside config.tests/unix/glib/glib.cpp during compilation. I supposed only to have changed 4.5.2 to 4.6 and changed the bz2 Nov 19 11:40:17 apart from this trip today i will pretty much rest the rest of the year at home Nov 19 11:40:31 have cancelled all my league games :( Nov 19 11:41:23 recalcati: configure with -v... is is still using pkg-config to find glib? Nov 19 11:42:08 MACHINE=dm365-evm bitbake -v -b recipes/qt4/qt4-embedded_4.6.bb -c compile . I used Nov 19 11:42:15 trhough away -v ? Nov 19 11:42:27 * mickey|munichHBF moves on to meeting Nov 19 11:43:12 the same glib.cpp:44:18: error: glib.h: No such file or directory Nov 19 11:43:23 mmm I re-verify the recipes Nov 19 11:44:07 03Sebastian Spaeth  07org.openembedded.dev * rd60924830b 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: Nov 19 11:44:07 fsodeviced: bump sane rev to get audio fixes Nov 19 11:44:07 Signed-off-by: Sebastian Spaeth Nov 19 11:49:43 recalcati: I asked a simple questiom :) Nov 19 11:51:24 zecke: do you know whether tinderclient.bbclass is still operational, and (if yes) which version of the tinderbox server it works with? Nov 19 11:53:19 03Koen Kooi  07org.openembedded.dev * rdb07c130e6 10openembedded.git/recipes/tasks/task-boot.bb: task-boot: move kernel to rrecommends so it can be uninstalled when providing it outside the rootfs Nov 19 11:53:28 pb_: good question, give me a second Nov 19 11:53:30 03Koen Kooi  07org.openembedded.dev * r279e7501b2 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev Nov 19 11:55:17 zecke: tell me Nov 19 11:58:07 recalcati: look at the configure output, is it using pkg-config to find glib? Nov 19 11:58:22 pb_: good question. It used to work with tinderbox1 Nov 19 11:58:52 zecke: righto. I was thinking that I might try to set up tinderbox3 for monitoring oe builds. Nov 19 11:59:32 pb_: it might be better to use oestat? Nov 19 11:59:46 zecke: yeah, I looked at oestats but it doesn't really seem to have the right sort of ui Nov 19 11:59:46 pb_: see oestats-client.bbclass Nov 19 12:00:11 unless there is a tinderbox-style ui that I failed to spot when I looked at the web interface before Nov 19 12:00:30 pb_: oh, you want to have the waterfall like view? Nov 19 12:00:40 right Nov 19 12:01:38 pb_: My gut instinct would be to add one to oestats but I've not looked at the details Nov 19 12:01:38 pb_: I didn't know there is a tbox3 but version1 and version2 were horrible. did you already setup v3? Nov 19 12:01:58 zecke: no, not yet. Nov 19 12:02:00 going to lunch Nov 19 12:02:09 pb_: but yeah, I agree with RP... oestats is using django and adding a new view should be trivial Nov 19 12:02:14 I do remember v1 being fairly horrible from when I looked at it before. Nov 19 12:03:04 pb_: e.g. with django and moddern "object mappers" doing a waterfall could be mostly done with the template language Nov 19 12:04:29 yeah, I could have a go at that. I was kind of hoping to avoid writing much/any code, which is why tinderbox seemed attractive. Nov 19 12:04:48 pb_: I can have a go on this over the weekend (or maybe tonight), this would avoid you doing it (I really like django) Nov 19 12:05:04 zecke: that would be awesome Nov 19 12:06:32 oestats-client doesn't currently seem to send a "zecke-rocks" variable but I imagine this could be arranged. :-} Nov 19 12:07:29 pb_: haha.. I try to git mv all patches containing my name to not contain it Nov 19 12:08:24 it didn't help me to find a job anyway... Nov 19 12:08:27 heh, clearly you still have some work to do Nov 19 12:08:43 pb_: haha Nov 19 12:08:46 I wonder how many instances of "mickey_is_cool" we still have in the tree :-} Nov 19 12:09:58 pb_: I thought it would help me to be more known... ironically everyone around me is getting jobs and I wonder how... because whenever I send a mail to hr@FOO they don't even bother to respond Nov 19 12:10:29 pb_: I'm obviously missing out on something... :) Nov 19 12:11:07 RP: maybe that is why you have a job. :) Nov 19 12:11:35 zecke: The sad fact is jobs are also a lot to do with who you know... Nov 19 12:11:45 zecke: I'd have thought you'd not have a problem there though Nov 19 12:12:16 RP: oh I'm happy with my current situation. It is just funny that HR never bothers to even reply Nov 19 12:12:28 zecke: it is rather poor form for them never even to reply to you. Nov 19 12:12:44 zecke: maybe you have sent so many applications that you are now blacklisted for spamming :-} Nov 19 12:13:25 zecke: they sound like typical hr departments :( Nov 19 12:13:40 pb_: nah, I thought for a company with offices in Taiwan to help me solve my visa problem. I used their web foo... no response Nov 19 12:14:03 anyway :) Nov 19 12:14:09 pb_: I have the oestats source now Nov 19 12:14:20 zecke: drat, that is bad. though, in fact, you are not alone: my wife has often had the same experience. Nov 19 12:15:03 * RP did once wind up an HR department over the date of the end of a contract. They were going to pay me for 5/7ths of a week so I was going to work 5/7ths of my weekly hours Nov 19 12:15:39 They were not amused and turned it into a serious dispute :) Nov 19 12:17:17 hehe Nov 19 12:17:52 pb_: okay, I got the source, got it configured... I will play with it when I'm back in the hotel tonight Nov 19 12:19:49 03Sebastian Spaeth  07org.openembedded.dev * rbd55c96e0d 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: Nov 19 12:19:49 fso-specs: bump sane ref to latest existing Nov 19 12:19:49 Signed-off-by: Sebastian Spaeth Nov 19 12:23:25 zecke: great, thanks Nov 19 12:31:03 re Nov 19 12:31:15 hrw: wb Nov 19 12:39:04 hrw, this is my machine file http://pastebin.com/m5bd34c62 Nov 19 12:40:01 kristoffer: and linux-jlime-ben recipe? Nov 19 12:40:06 one sec Nov 19 12:41:31 hrw, http://pastebin.com/m4d0ad595 Nov 19 12:41:38 perhaps its the r0 thing? Nov 19 12:41:48 wtf Nov 19 12:41:51 doh! Nov 19 12:41:55 its says jornada7xx Nov 19 12:42:04 ;d Nov 19 12:42:19 lol, thx man. Nov 19 12:42:34 kristoffer: you know that you can merge that recipe into linux_2.6.31.bb? Nov 19 12:42:47 and that this will be suggested on merge? Nov 19 12:43:40 hrw, hmm, will look at it. Just want to see it built first before I merge it. Nov 19 12:44:12 sure Nov 19 13:09:01 machine override has higher priority if its sooner defined in OVERRIDES right? and thas usuall to have machine before architecture Nov 19 13:09:55 then why is SRC_REV_arm used in ffmpeg_git if i have there SRCREV = "DEADBEEF12345678" Nov 19 13:09:58 SRCREV_arm = "d886804643d7427debfa70d824de7e53ae8e3e83" Nov 19 13:10:01 SRCREV_om-gta02 = "615493470b73a1efb2f8e5b910efd700657123d9" Nov 19 13:10:09 and building for om-gta02.. Nov 19 13:16:21 grep ^SRCREV= ffmpeg.env -> SRCREV="d886804643d7427debfa70d824de7e53ae8e3e83" Nov 19 13:16:40 grep ^OVERRIDES= ffmpeg.env -> OVERRIDES="local:om-gta02:${MACHINE_CLASS}:shr:linux-gnueabi:arm:build-linux:fail-fast:pn-ffmpeg:armv4t:libc-glibc" Nov 19 13:18:53 03Koen Kooi  07org.openembedded.dev * re53bdd16a3 10openembedded.git/recipes/mplayer/mplayer_svn.bb: mplayer svn: bump SRCREV Nov 19 13:18:54 03Koen Kooi  07org.openembedded.dev * r93a3510ed8 10openembedded.git/conf/checksums.ini: checksums: add checksums for 2.6.24.X stable patches Nov 19 13:18:54 03Koen Kooi  07org.openembedded.dev * rd9761b32ac 10openembedded.git/recipes/ffmpeg/ffmpeg_svn.bb: ffmpeg svn: bump SRCREV and tweak default pref a bit Nov 19 13:19:45 when compling a packages I see **gcc** -I/awrongstagingpath . I'm recompiling. How can I inspect STAGING_INCDIR ? Nov 19 13:20:02 JaMa|Wrk: overrides are processed left to right, so the ones that are named later take precedence. Nov 19 13:20:45 you generally want them to go from least to most specific in ${OVERRIDES} Nov 19 13:21:13 its very funny, the path is longer http://pastebin.com/f3f5e8dd Nov 19 13:22:09 recalcati: I don't understand your question Nov 19 13:22:10 JaMa|Wrk: as a quick hack, if it is difficult for you to change ${OVERRIDES} then I suspect changing your second variable to be SRCREV_arm_om-gta02 = "..." will probably do what you want. Nov 19 13:22:59 qt 4.5.2 compiles and find glibc.h inside /app/opt/sources/DM365_TI_PSP/scratch/arago-tmp/staging/armv5te-none-linux-gnueabi/usr/include/glib-2.0 Nov 19 13:23:43 instead my qt 4.6 recipe doens't , because it selects /app/opt/sources/DM365_TI_PSP/scratch/arago-tmp/staging/armv5te-none-linux-gnueabi/app/opt/sources/DM365_TI_PSP/scratch/arago-tmp/staging/i686-linux/usr/include/glib-2.0 non existent dir Nov 19 13:24:10 Down to seven legacy staging packages in poky Nov 19 13:24:10 it is duplicated Nov 19 13:24:59 any idea ? Nov 19 13:25:08 pb_: thanks! seems like quick hack arrived to ffmpeg_svn just now :) but from bitbake.conf i read "And finally '_local' overrides anything." and local is there first in OVERRIDES.. Nov 19 13:25:20 RP: very good! Nov 19 13:25:45 pb_: ah maybe I see now.. Nov 19 13:26:04 pb_: its about how specific that override is.. not about priority.. Nov 19 13:26:54 app....longpatch....app.....anotherlongpath Nov 19 13:27:32 JaMa|Wrk: if bitbake.conf has a comment saying that "_local" is the highest priority override, I think that is just plain wrong. if local is first, it will be the lowest priority one. Nov 19 13:28:31 you can try it for yourself; create a little bb file containing something like: Nov 19 13:28:34 foo = "1" Nov 19 13:28:34 foo_arm = "2" Nov 19 13:28:34 foo_local = "3" Nov 19 13:28:39 pb_: no it says "And finally '_local' overrides anything." which is right from "how specific override" is view, right? Nov 19 13:28:40 and then run it with bitbake -e and see what you get. Nov 19 13:29:02 pb_: arm_om-gta02 worked too as you said.. Nov 19 13:29:20 JaMa|Wrk: ah, right. I think that is an unfortunate choice of wording in the comment. Nov 19 13:29:34 recalcati: compare qt 4.5.2 recipe with yours Nov 19 13:29:40 * RP wonders what to do with cross-linkage and staging-linkage Nov 19 13:30:23 pb_: hmm # This means that an envionment variable named '_arm' overrides an Nov 19 13:30:23 # environment variable '' (when ${TARGET_ARCH} is arm). And the same: an Nov 19 13:30:23 # environment variable '_ramses' overrides both '' and '_arm Nov 19 13:30:23 # when ${MACHINE} is 'ramses'. And finally '_local' overrides anything. Nov 19 13:30:24 I suppose it was trying to say that a _local override is unconditional (i.e. will always apply irrespective of configuration), not that it will take precedence over other overrides. Nov 19 13:30:59 JaMa|Wrk: oh. in that case, I return to my previous statement: the comment is just wrong. Nov 19 13:31:08 pb_: yes :) Nov 19 13:31:39 based on the value of OVERRIDES that you mentioned, I think the actual situation is the exact opposite of what the comment says. Nov 19 13:31:42 first and last can be understand right Nov 19 13:32:06 second sentence is wrong wrt you said and I tested Nov 19 13:33:08 mckoan: I found a difference, I'm recompiling, but I'd like to print somewhere the values of environment variables Nov 19 13:53:29 03Sebastian Spaeth  07org.openembedded.dev * ra1a4e6d428 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Nov 19 13:53:29 shr-settings: bump sane revs, to catch up with fso2 Nov 19 13:53:29 Signed-off-by: Sebastian Spaeth Nov 19 13:55:51 INCPATH inside QT Makefile is wrong Nov 19 13:56:45 recalcati: someone is adding the "sysroot" again? Nov 19 13:57:30 I can imagine is my fault, because I'm practising, but what you mean? Nov 19 13:58:00 recalcati: the glib-2.0 should come from a call like `pkg-config --cflags glib-2.0` Nov 19 13:58:10 recalcati: this looks at a file called glibc-2.0.pc... Nov 19 13:58:28 recalcati: in this file you will see something like /usr/include/glib-2.0 Nov 19 13:58:49 recalcati: and the pkg-config file appends it s SYSROOT in front to that path Nov 19 13:58:58 qt 4.5.2, that compiles, uses /app/opt/sources/DM365_TI_PSP/scratch/arago-tmp/staging/armv5te-none-linux-gnueabi/usr/include/glib-2.0 Nov 19 13:59:53 recalcati: did you hear what I said? Nov 19 14:00:14 yes, I'm investigating , thx Nov 19 14:19:06 Hello Nov 19 14:19:24 I think it is easier to talk about the merging stuff here :-) Nov 19 14:20:22 So we, at company, has some specific packages that we use to build our images here so we basically use a branch that is based on stable/2009 and we merge stable/2009 on this branch from time to time. Nov 19 14:20:53 yeah Nov 19 14:20:58 This branch also has few other changes that we cherry-picked from .dev to support things we needed (as for example some mips related fixes) Nov 19 14:21:25 I'm starting to worry about how we will update this branch to stable/2010 when it comes out Nov 19 14:21:44 basically, everyone has different ideas how to manage a "stable" branch Nov 19 14:22:01 So I played with a merge try from it with dev (since stable/2010 are going to be based on that) Nov 19 14:22:01 well, not everyone, but I think they fall into several groups Nov 19 14:22:15 and it looks like it will be a nightmare :-) Nov 19 14:22:21 my view is make sure important fixes get into dev Nov 19 14:22:41 Crofton|work: and then the guy need to "redo" the work into dev? Nov 19 14:22:47 then stable/2010 will branch from .dev at some point in the future Nov 19 14:23:01 Crofton|work: I do it; since we basically use stable here and I always port the changes to dev to push it Nov 19 14:23:03 without knowing specifics, it is hard to say Nov 19 14:23:15 Crofton|work: it is how I described above Nov 19 14:23:22 you may want to keep your stuff in an overlay Nov 19 14:23:22 Crofton|work: imagine a branch that has forked stable Nov 19 14:23:45 then you can overlay it on dev/stable2009 and future stable branchs Nov 19 14:23:56 Crofton|work: yes; it starts to look easier to do this way Nov 19 14:24:01 yeah Nov 19 14:24:23 I understand the need to "upgrade" the product from stable2009 to stable 20xx Nov 19 14:24:35 Crofton|work: but even doing this, it looks like a lot of people will require a way to update it Nov 19 14:24:42 but many people will want to use stable2009 for the entire life cycle of their product Nov 19 14:25:11 Crofton|work: from my POV if we merge stable/2009 into dev this reduces a lot the trouble Nov 19 14:25:25 It is really hard to accomodate the needs of people with out of tree stuff Nov 19 14:25:26 Crofton|work: since only the speicific are going to be merged then Nov 19 14:25:34 (out of tree stuff is Ok though :) Nov 19 14:26:19 I don't have anything like what you describe, so it is hard for me to understand your exact use case Nov 19 14:26:32 Crofton|work: how do you manage it? Nov 19 14:26:33 I understand otavio Nov 19 14:26:54 hrw: oh! finally someone sees my point :P Nov 19 14:26:55 haha Nov 19 14:27:04 Crofton|work: currently we did .dev->stable/2009 and then we will do .dev->stable/2010 Nov 19 14:27:39 Crofton|work: AIUI e wants to merge stable/2010 into his existing branch so he'd like dev to have already resolved the merge with 2009 when it gets forked off to be 2010 Nov 19 14:27:43 Crofton|work: otavio's problem is that stable/2009 is not 'old .dev' + fixes from .dev but rather 'old .dev' + changes adapted from .dev Nov 19 14:28:12 hrw: exactly Nov 19 14:28:46 and I do believe stable/XXXX needs to be merged into .dev from time to time to avoid merging conflicts for next stable Nov 19 14:28:50 hrw: Even if there were no adaption there'd be an issue due to not all changes getting backported. Nov 19 14:28:52 otavio: the problem is that it could not be done other way Nov 19 14:29:14 The other option is to do the merge immediately after forking 2010 Nov 19 14:29:24 hrw: the "right" way of handling it would be commiting stuff into stable and merging this "fixes" into .dev Nov 19 14:29:36 broonie: belive me, it will be hard Nov 19 14:29:51 otavio: Right, but that's going to happen at least once anyway. Nov 19 14:29:56 broonie: specially due the changes that are going to be done now Nov 19 14:30:06 broonie: that's why I think this merge could be done _now_ Nov 19 14:30:10 bb in some Nov 19 14:30:43 otavio: how to port 3m old change to stable then? Nov 19 14:30:48 but from my point of view, updating stable2009 to have the recent changes from dev makes it unstable Nov 19 14:31:13 Crofton|work: NO Nov 19 14:31:20 Crofton|work: other way Nov 19 14:31:30 Crofton|work: you go to .dev and merge stable into dev Nov 19 14:31:34 Crofton|work: not dev into stable Nov 19 14:31:39 otavio: as I asked on the list, what exactly are the changesets from the current stable that you feel are missing in .dev at the moment? Nov 19 14:31:53 I still cannot understand what there actually is to merge. Nov 19 14:31:55 pb_: I believe the idea is that there should be no changes to dev at all as aresult of the merge. Nov 19 14:31:56 pb_: nothing. The problem is not missing change Nov 19 14:32:06 broonie: exactly Nov 19 14:32:07 pb_: Thep oint is to have the history record this fact. Nov 19 14:32:31 broonie: in theory it would be no conflict but in pratical it produces a lot of them Nov 19 14:32:44 pb_: So that later on when someone merges stable/2010 into their stable/2009 based branch git gets a big hint about what to do. Nov 19 14:32:48 pb_: so it is easier to merge forked trees into "new stable" Nov 19 14:33:07 broonie: you got it :-) Nov 19 14:33:26 and I'm sure I'm not the only one with this problem; most are not noticing it right now. Nov 19 14:34:01 I suspect a lot of people will instead re-fork from 2010 and rebase their changes onto it Nov 19 14:34:02 maybe we need to go at this from a different direction Nov 19 14:34:12 what workflow for stable would make your life easier? Nov 19 14:36:22 Crofton|work: commit in stable and merge the changes into dev Nov 19 14:36:37 otavio: again: how to port 3m old change to stable then? Nov 19 14:36:38 Crofton|work: this is how projects that has 'maint' branches work most of time Nov 19 14:36:58 hrw: you can do it and merge it into .dev again Nov 19 14:37:08 pb_, otavio: I think I understand what otavio wants - he has local changes against stable committed into his version of the stable tree. Its these commits he wants to forward port Nov 19 14:37:10 hrw: the history will be a bit ugly but it works Nov 19 14:37:19 RP: yes Nov 19 14:37:23 otavio: example: maintainer of XYZ machine do not care about stable branch. 3 months later user of XYZ wants to use stable for it Nov 19 14:37:25 * broonie nods RP Nov 19 14:37:39 I just replied to the list Nov 19 14:37:56 otavio: maintainer of XYZ commits only to .dev not to stable. how you want to handle that? Nov 19 14:38:17 hrw: if it is important enough to the project he could propose the porting for merging into stable and then we ought to merge it _back_ into .dev (even though it will just record a merge commit) Nov 19 14:38:42 hrw: but most of time, we will not add "new machines" or like, just bugfixes Nov 19 14:38:49 otavio: what if it is not important at time? Nov 19 14:39:09 otavio: I added BUG into stable/2009 because it was required there for my work Nov 19 14:39:16 hrw: but it doesn't matter ... Nov 19 14:39:29 hrw: you could have done it in your local tree as well Nov 19 14:39:38 hrw: as i did for mips changes (since they were many) Nov 19 14:39:54 otavio: I do not want to maintain vendor branch if not need Nov 19 14:40:17 otavio: I still think git-merge with the "ours" stratergy against a plain .stable to .dev tree and then trying to merge that with a tree with your local changes is going to be the best way forwards Nov 19 14:40:43 RP: right, thanks, now I understand. I guess I had imagined that everybody would handle that by just rebasing their changes onto the new stable branch, rather than by merging the new work into their existing branch. Nov 19 14:40:46 RP: I think that's what Otavio was suggesting, except that that be done in dev. Nov 19 14:41:00 ie, do that and then push the commit. Nov 19 14:41:19 hrw: neither I want to lose my work if not need ;-) Nov 19 14:41:40 broonie: That has some merit in that it means a merge with .dev of his local branch should take hints from that merge Nov 19 14:42:00 RP: Yes, exactly. Nov 19 14:42:09 RP: yes; I can try it here and see how it goes Nov 19 14:42:20 broonie: I'd be interested to see how git handles it Nov 19 14:42:32 * mwester notices that the ML has become unusually noisy lately. Nov 19 14:42:34 RP: seems to work mostly OK for the kernel. Nov 19 14:42:56 broonie: I suspect this is a lot more distant though Nov 19 14:43:21 RP: Yeah, but once it's done once if people keep doing it regularly it ought to be less painful. Nov 19 14:44:03 03Martin Jansa  07org.openembedded.dev * r4f1f60e0f4 10openembedded.git/recipes/mplayer/mplayer_git.bb: Nov 19 14:44:03 mplayer: add git version with glamo patches for om-gta02 Nov 19 14:44:03 Signed-off-by: Martin Jansa Nov 19 14:44:38 broonie: I'd just like to know if it actually works Nov 19 14:44:54 RP: didn't change much Nov 19 14:45:01 RP: I just tryed it here Nov 19 14:45:23 otavio: So git isn't as clever as I'd hoped :( Nov 19 14:45:41 RP: or I did something stupid here but I guess not Nov 19 14:45:43 git does not pass the Turing test Nov 19 14:45:52 * otavio goes have lunch Nov 19 14:46:02 Someone should ask the git list :} Nov 19 14:47:18 bbl Nov 19 15:06:37 morning Nov 19 15:07:24 hi kergoth Nov 19 15:07:56 poky is now legacy staging free. Now to run some extensive build tests... Nov 19 15:08:18 sweet, grats :) Nov 19 15:17:06 what thread on the list involved the git question from this morning, out of curiosity? I find that sort of thing interesting Nov 19 15:21:18 re Nov 19 15:21:37 kergoth: [oe] [RFC] Merging of stable/2009 into dev Nov 19 15:21:40 ah Nov 19 15:21:46 thanks Nov 19 15:22:57 hi kergoth Nov 19 15:23:18 re Nov 19 15:27:09 zecke: it is ok. hte configure was http://pastebin.com/f79a55886 : configure doesn't use pkg-config. looking at config.tests/unix/glib/Makefile the INCPATH is good, and now it works! it was, I suppose, a patch, that set this path. Nov 19 15:28:26 recalcati: it should use pkg-config Nov 19 15:30:03 zecke: now I have another problem inside qt, due to scratchbox.config , I have to fix. Thx. May debugging method is slowly improving Nov 19 15:31:32 recalcati: great, it is good to learn tricks :) Nov 19 15:32:37 zecke: getting crazy a little bit Nov 19 15:39:46 Henning, around? What's the iconv problem? Nov 19 15:46:40 kergoth: any solution for it in mind? Nov 19 15:47:01 working on real work, give me a few :) Nov 19 15:52:23 03Klaus Kurzmann  07org.openembedded.dev * r276aba6a10 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Nov 19 15:52:23 sane-srcrevs.inc: bump rev for pyphonelog Nov 19 15:52:23 Signed-off-by: Klaus Kurzmann Nov 19 15:56:33 pb_: .. that bitbake.conf comment can go in, or should I describe it better? I commited that accidentally only to shr/merge branch.. Nov 19 15:58:28 JaMa|Wrk: I think the "you can use combination" part is a bit misleading. If you remove that line then I would be happy for you to check in the rest, though you might want to get a second opinion from one of the bitbake h4x0rs. Nov 19 16:00:06 bbl Nov 19 16:09:11 03Koen Kooi  07org.openembedded.dev * r321d969579 10openembedded.git/recipes/mplayer/mplayer_git.bb: mplayer git: kill SRCPV, no SRCPV for git allowed yet Nov 19 16:10:35 Is it okey, to define KERNEL_IMAGETYPE inside machine file? Or should it be contained inside kernel recipe (using linux_2.6.31) Nov 19 16:10:52 currently only uImage is supported and it always defaults to zImage Nov 19 16:10:58 should be fine Nov 19 16:11:28 oki, thx Nov 19 16:16:54 kristoffer: it is machine specific thing so machine config is proper place Nov 19 16:16:58 h4x0rs? Nov 19 16:17:27 * mwester puts pb_ in the corner for a "timeout" Nov 19 16:17:48 kristoffer: and when you do that in machine config then you do not need to copy it from kernel recipe to kernel recipe Nov 19 16:18:38 hrw, agreed. Since it currently only supports uImage I agree, however when zImage starts working I guess I could just delete the line from machine file. Nov 19 16:18:47 kristoffer: yep Nov 19 16:19:03 kristoffer: you have uboot on it? Nov 19 16:19:54 hrw, yes, so it seems. Got this device on monday, but from what I understand u-boot is on it (no serial, so dont actually see it) Nov 19 16:21:17 hrw, ah right. You are saying that it might not need zImage after all :) (atleast not so long u-boot is on there) Nov 19 16:21:39 u-boot is fine bootloader Nov 19 16:22:18 agreed. If I just could get it to work on my jornada (sa1100 based) I would be happy :) Nov 19 16:26:54 ~hail git svn! Nov 19 16:26:55 * ibot bows down to git svn! and chants, "I'M NOT WORTHY!!" Nov 19 16:27:31 mwester: mm? Nov 19 16:29:59 Are you "l33t" too? :-D Nov 19 16:30:51 ah, heh Nov 19 16:30:52 * mwester finds the strange spelling rather humorous... Nov 19 16:52:50 good morning all Nov 19 16:57:20 jo Nov 19 16:57:34 anyone familiar with a variable called STAGE_TEMP? Nov 19 16:59:51 kg4ysn: sounds like 'I am variable which you should not touch' Nov 19 17:00:28 hrw: i'd be happy to ... except db4 seems to use it, and I'm having problems compiling db4. Nov 19 17:00:37 (trying to upgrade to db 4.8.24. Nov 19 17:00:41 jo hrw Nov 19 17:15:35 kgilmer: STAGE_TEMP is a DESTDIR for staging Nov 19 17:15:51 anybody knows what does it mean: /scratchbox/tools/bin/misc_runner: /targets/links/scratchbox.config: No such file or directory ? compiling qt Nov 19 17:15:55 hi rp Nov 19 17:16:05 hi woglinde Nov 19 17:16:08 rp sorry didnt test your uclibc changes yet Nov 19 17:16:12 but maybee later today Nov 19 17:16:20 woglinde: its ok, no rush Nov 19 17:17:10 biah Nov 19 17:17:13 power7 Nov 19 17:17:18 ibm rockz Nov 19 17:31:38 hi oh5 Nov 19 17:31:43 ups ph5 Nov 19 17:32:01 hi woglinde Nov 19 17:41:12 03Martin Jansa  07org.openembedded.dev * r5238516421 10openembedded.git/recipes/ (72 files in 13 dirs): Nov 19 17:41:12 recipes from shr: kill SRCPV, no SRCPV for git allowed yet Nov 19 17:41:12 Signed-off-by: Martin Jansa Nov 19 17:58:31 03Martin Jansa  07org.openembedded.dev * r20644160b1 10openembedded.git/recipes/xorg-util/glamo-dri-tests/glamo-dri-tests_git.bb: glamo-dri-tests: move to better directory, included in BBFILES Nov 19 18:23:45 03Jeremy Lainé  07org.openembedded.dev * re27dc19698 10openembedded.git/conf/checksums.ini: checksums.ini: add missing entry for wbxml2 0.10.7 Nov 19 19:05:58 03Otavio Salvador  07org.openembedded.dev * re0663b3879 10openembedded.git/recipes/squashfs-tools/ (squashfs-tools.inc squashfs-tools_4.0.bb): Nov 19 19:05:58 squashfs-tools: add .inc usage again to avoid duplicated logic Nov 19 19:05:58 In the effort to avoid duplicated code we've added back the .inc usage Nov 19 19:05:58 otherwise most of code and compilation logic is duplicated between 3.3 Nov 19 19:05:58 and 4.0 recipes. Nov 19 19:05:59 Signed-off-by: Otavio Salvador Nov 19 19:06:03 03Otavio Salvador  07org.openembedded.dev * r5555bc82e5 10openembedded.git/recipes/lzma/lzma.inc: Nov 19 19:06:06 lzma.inc: use CXX and CC environment values to really do cross compile Nov 19 19:06:08 Signed-off-by: Otavio Salvador Nov 19 19:07:12 likewise: ^ Nov 19 19:07:40 likewise: I didn't change the recipe to use lzma sources from the recipe but I did fix lzma compilation issue you had Nov 19 19:07:57 likewise: please, could you check how difficult would be to use lzma regular source? Nov 19 19:11:51 why is there no oe linux-omap3 recipe? Nov 19 19:13:24 awozniak: what should it do? Nov 19 19:14:57 zecke: there's linux-omap, linux-omap1, linux-omap2 ; they build the kernel for omap,omap1,omap2. The overo git branch also has a linux-omap3 Nov 19 19:15:36 awozniak: well, beagleboard is omap3 right? and it builds with linux-omap2 :) Nov 19 19:20:12 03Martin Jansa  07org.openembedded.dev * r70af4a8829 10openembedded.git/conf/bitbake.conf: Nov 19 19:20:12 bitbake.conf: Fix OVERRIDES description (After pb's explanation) Nov 19 19:20:12 Signed-off-by: Martin Jansa Nov 19 19:22:54 am I the only one that thinks 6 threads about guile today are five too many? Nov 19 19:25:50 zecke, we are premptively fixing a problem before we start having loads of F12 users :) Nov 19 19:29:39 zecke: :) Nov 19 19:33:25 Crofton|work: one thread would have done though Nov 19 19:33:45 zecke: yeah, I think we could probably have managed without the minute-by-minute commentary on guile. but, well, threads are cheap. Nov 19 19:34:17 I am still getting two copies of all the mails as well. I should unsubscribe one of my accounts. :-} Nov 19 19:38:50 byee Nov 19 19:49:26 pb_: heh, gmail's mute function is my friend (re guile threads) Nov 19 20:06:59 otavio: thanks, I'm a bit busy these days but I have noted it on my todo. Nov 19 20:14:30 hmmm, is a pref. version change from some of the SHR inports make it over without the recipe? NOTE: preferred version 0.0+1.0rc2+svnr29789 of mplayer not available (for item mplayer) Nov 19 20:14:57 we noticed some QA issue at SHR and solved them by adding TARGET_CC_ARCH += "${LDFLAGS}" e.g.: http://patchwork.dev.bearstech.com/patch/472/ should we commit these to org.oe.dev or not? Nov 19 20:16:26 03Martin Jansa  07org.openembedded.dev * r2cdd046f46 10openembedded.git/recipes/gtk-webcore/ (midori/config midori/ua-iphone-0.1.10.patch midori_0.1.10.bb): Nov 19 20:16:26 midori: add shr specific patch Nov 19 20:16:26 Signed-off-by: Martin Jansa Nov 19 20:16:29 Heinervdm: lots of those changes made there way into OE in lew of a better solution Nov 19 20:16:38 03Thomas Zimmermann  07org.openembedded.dev * r1f373d7669 10openembedded.git/recipes/gtk-webcore/midori_0.2.1.bb: Nov 19 20:16:38 midori: add shr config for midori Nov 19 20:16:38 Signed-off-by: Martin Jansa Nov 19 20:16:38 03Thomas Zimmermann  07org.openembedded.dev * r00e6bf1fa9 10openembedded.git/conf/machine/om-gta02.conf: Nov 19 20:16:40 om-gta02.conf: correct fbreader spezific config variables Nov 19 20:16:42 Signed-off-by: Martin Jansa Nov 19 20:17:23 DJWillis: ok, then we won't commit them Nov 19 20:19:11 Heinervdm: no, I mean that sort of fix is valid, esp. if OE mainline is in essence broken for that recipe ;) - I am not an OE dev so don't take my word for it. Nov 19 20:19:13 kergoth: ah, good thinking Nov 19 20:20:10 DJWillis: ah ok, then we will commit it if no one says something against it :) Nov 19 20:20:36 anyone know of a patch to make an openssl install relocatable, wrt its engines & certs dirs? Nov 19 20:20:48 hmm Nov 19 20:22:56 kergoth: if you find one let me know Nov 19 20:27:29 i guess the Right solution would be to patch it to use binreloc to determine the default paths Nov 19 20:38:59 03Leon Woestenberg  07org.openembedded.dev * rce1c7e98a3 10openembedded.git/conf/machine/ (include/tune-atom.inc ion.conf): Nov 19 20:38:59 conf/machine/ion.conf: NVidia Ion based x86 machines. Nov 19 20:38:59 This introduces tune-atom.inc, using core2 arch as we can rely on Nov 19 20:38:59 GCC 4.3.1+, which supports core2 reliably. Nov 19 20:39:00 Signed-off-by: Leon Woestenberg Nov 19 20:43:55 * kergoth wishes more projects cared about being relocatable, its a useful thing Nov 19 20:45:49 * mwester wishes the code generators would all default to relocatable, which would resolve the issue. Nov 19 20:46:44 unless your compiler is going to mangle every -D, that's not going to happen anytime soon :P Nov 19 20:47:11 * kergoth grumbles Nov 19 20:48:12 What does a macro def have to do with generating code that can be relocated? Nov 19 20:48:28 heh, I think you two might be talking at cross purposes. Nov 19 20:48:30 oh, i mean relocatable installs, not relocatable objects. Nov 19 20:48:34 aye, the term is overloaded Nov 19 20:48:36 Oh - sorry! Nov 19 20:48:41 but yes, that would be good too :) Nov 19 20:48:42 filesystem relocatable, not in-memory relocatable Nov 19 20:48:42 oops. Nov 19 20:48:42 heh Nov 19 20:52:23 as for making everything -fpic by default, yeah, that's not a completely silly idea. it'd make your binaries a bit slower but I doubt anybody would really notice in 99% of cases on modern hardware. Nov 19 20:59:25 Quick Question about kerenel modules: How do I clean them? For example I was using 2.6.28 and buitt an image with that. I did "virtual/kerenel -c clean" and played around with 2.6.30 a bit, but now I want to switch back to 2.6.28. So I 'virtual/kerenel -c clean' again with 2.6.30 and -rebuild the x11-image. g_ether for 2.6.30 is getting put on the root filesystem newley built rootfs. I was hoping for something like a "bitbake kernel-modules -c clean" type thin Nov 19 21:01:23 NvrBst: Have you tried "bitbake kernel-modules -c clean" when your PREFERRED_VERSION was still 2.6.30 ? Nov 19 21:01:53 I get an: ERROR: Nothing PROVIDES 'kernel-modules' Nov 19 21:02:21 kernel-modules is a binary package, not a recipe Nov 19 21:04:24 Ahh which recipie creates/cleans that binary package? Or best way to fix something like this is a "rm -rf tmp" "bitbake x11-image" type thing hehe? Nov 19 21:05:51 it's virtual/kernel or linux, as you were doing, but clean doesn't remove the binary packages from tmp/deploy/ipk/*/, so perhaps thats acting up. I'd suggest manually killing the packages with the version you dont want from tmp/deploy/ipk/*/ to be absolutely certain Nov 19 21:06:37 kergoth: that is one of hardest things to someone get used to OE Nov 19 21:06:47 kergoth: we ought to provide a task for it Nov 19 21:06:48 i agree, clean should really remove them Nov 19 21:07:11 kergoth: I don't think clean ought to remove them but a task for it would be really useful Nov 19 21:07:14 okay i'll try that :) I did look for "*2.6.30*" and it only shows up in the "deploy" and "rootfs" directories. I'll remove and try "bitbake x11-image -c rebuild -f" again Nov 19 21:07:19 would have to modify do_clean from package_ipk to use pkgdata to remove them Nov 19 21:07:32 since the actual generated packages aren't known until do_package time Nov 19 21:08:37 hum Nov 19 21:09:35 shouldn't be horribly difficult to pull off, would have to do it for each package_ class individually though Nov 19 21:09:42 since they know the package filenaems Nov 19 21:14:06 is package_tar removed? only getting ipk currently Nov 19 21:21:43 kristoffer: what do you mean? Nov 19 21:21:53 kristoffer: "removed"? its sitting in the repo just fine. it might not create them by default given the DISTRO you use, but it's certainly there Nov 19 21:26:43 kergoth, yeah I saw it. Been running through my config files to spot anything. Nov 19 21:28:55 INHERIT += package_tar if you need to enable it Nov 19 21:29:29 kergoth, I got that. Looking for something that might override it. Thing is that it worked last night. Then I cleared out my /tmp and started to only get ipk. Nov 19 21:29:54 I'd do a bitbake -e | grep \^INHERIT= and see if its what you think it is :) Nov 19 21:30:10 kergoth, sweet, thx Nov 19 21:30:37 bitbake -e to see the config metadata, bitbake -e to see ther ecipe's data. incredibly useful for validating assumptions when debugging Nov 19 21:32:03 INHERIT="debian package_tar package_ipk src_distribute_local src_distribute sanity so should be there. :) So must have missed something. Doing another build to check. Nov 19 21:32:08 weird. Nov 19 21:32:52 I only had built 2-3 packages that turned out ipk, maybe tar creating comes later on?.. Nov 19 21:33:29 *shrug* starting from scratch anyhow so should be alright now I guess. Nov 19 21:33:44 it's possible, depending on the order of the tasks in the runqueue Nov 19 21:34:20 hmm, oki. sounds resonable. I was halfway through console-image. Nov 19 21:38:32 What's the documentation on MACHINE_ARCH? It's not in the user manual, and bitbake.conf doesn't bring me much. Nov 19 21:39:55 03Klaus Kurzmann  07org.openembedded.dev * rf73eb11941 10openembedded.git/recipes/tasks/task-fso2-compliance.bb: Nov 19 21:39:55 task-fso2-compliance: add tzdata-africa and tzdata-australia to rrecommends Nov 19 21:39:55 Signed-off-by: Klaus Kurzmann Nov 19 21:44:42 mwester: If you're reading this, do you know the definition of MACHINE_ARCH. ixp4xx seems one of the few users of it. Nov 19 21:45:37 gah, why does my build have to fail right at the end due to a makefile with "/usr/bin" harcoded :/ Nov 19 21:47:19 likewise: its so you can do PACKAGE_ARCH = "${MACHINE_ARCH}" because ${MACHINE} isnt a valid ARCH Nov 19 21:47:30 * Crofton|work grumbles about rday's commit message not being quite right :) Nov 19 21:47:41 I think I'll edut before I apply it Nov 19 21:48:03 what is the right way to apply somethign from an email, git-am seems to have gone away Nov 19 21:48:58 Crofton|work: git am is still there Nov 19 21:49:05 without the dash Nov 19 21:49:07 or it is here anyway Nov 19 21:49:09 Crofton: Try "git am" Nov 19 21:49:18 git command completion told me that :) Nov 19 21:49:20 Crofton|work: modern git removed the | from all commands Nov 19 21:50:22 XorA: Thanks, so MACHINE_ARCH must be a valid ARCH. But what is the definition of a valid ARCH? Those in sites/ ? Nov 19 21:50:34 likewise: dunno :-) Nov 19 21:50:48 likewise: PACKAGE_ARCHS ? Nov 19 21:51:02 there is some variable like that... Nov 19 21:51:27 there was some reason you couldnt do PACKAGE_ARCH = "${MACHINE}" but the reason escapes me Nov 19 21:52:15 Something messes with ${MACHINE} IIRC - perhaps when you build the toolchain/sdk? Nov 19 21:52:21 http://pastebin.ca/1678382 Nov 19 21:52:25 my git fu is poor Nov 19 21:52:57 RP: PACKAGE_ARCHS includes MACHINE, so that would make it round circle Nov 19 21:53:28 Crofton|work: git rebase --abort Nov 19 21:53:55 I think the guy running openembedded.info had it well documented, but that site is no longer... Nov 19 21:54:25 Wasn't Laibsch running openembedded.info, I cannot remember... Nov 19 21:54:32 likewise: I think the idea was that you could have a class of machines that could all run machine specific code whilst also still having machine specific packages Nov 19 21:55:18 RP: the reason I ask is I would like to add a new class: atom based machine but with two generations of CFLAGS newer than what poky has. Nov 19 21:55:48 when I do git am ../patch.file it fails with Nov 19 21:55:52 likewise: I keep meaning to add my atom optimisation branch to poky Nov 19 21:56:06 fatal: git apply: bad git-diff - expected /dev/null on line 11 Nov 19 21:56:13 line 11 is the mail headers Nov 19 21:56:33 RP: TARGET_CC_ARCH = "-march=i686 -mtune=atom" for gcc 4.4.2 Nov 19 21:56:35 Crofton|work: youll have to ask the fanbois Nov 19 21:56:44 likewise: I have better ones Nov 19 21:57:11 likewise: well, not sure actually, mine apply to earlier gccs Nov 19 21:57:11 RP: the secret intel ones :-) Nov 19 21:57:30 XorA: copied from moblin so not so secret Nov 19 21:57:53 03Leon Woestenberg  07org.openembedded.dev * r36aac4867a 10openembedded.git/conf/machine/ (include/tune-atom.inc ion.conf): ion.conf: TARGET_CC_ARCH = "-march=i686 -mtune=atom" for Atom. Nov 19 21:57:57 RP: core2 for gcc 4.3.1+, -march=i686 -mtune=atom" for gcc 4.4.2 AFAIK Nov 19 21:58:34 likewise: atom supports the core2 instructions but schedules them like a pentiumpro Nov 19 21:58:54 -march=core2 -tune=pentiumpro for older gcc I beleive Nov 19 21:59:04 RP: I know, non-speculative and in-order, wasn't it? Nov 19 21:59:11 likewise: -march=core2 -msse3 -mtune=generic -mfpmath=sse Nov 19 21:59:38 RP: I would like to go for GCC 4.4.2 right away and see how it behaves. Fedore 12 uses it for Atom. Nov 19 22:00:11 RP: Maybe I should add the SSE flags. OE .dev could be testing ground. Nov 19 22:00:11 likewise: Fancy adding it to poky? :) Nov 19 22:00:48 03Klaus Kurzmann  07org.openembedded.dev * r5c45acafcb 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Nov 19 22:00:48 sane-srcrevs.inc: bump rev for e-wm-config-illume-shr Nov 19 22:00:48 Signed-off-by: Klaus Kurzmann Nov 19 22:00:50 03Klaus Kurzmann  07org.openembedded.dev * rf9c281ca42 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git.openembedded.net/openembedded into org.openembedded.dev Nov 19 22:01:16 RP: Don't have commit access there, but you can cherrypick after I tested, or give me commit access, or Intel employeeship, or the winning lotery ticket, or the question to the ultimate answer, or ... Nov 19 22:01:40 likewise: You'd be welcome to access to the poky-contrib tree and I'd pull from there Nov 19 22:01:55 RP: tell me about your secret Atom branch. Does anyone know? :-) Nov 19 22:02:34 likewise: Its nothing interesting, I pushed everything except the flags an age ago :/ Nov 19 22:02:46 likewise: you just reminded me of it and I've pushed the flags now Nov 19 22:03:35 RP: ok, so the only question remaining would be how we would name the class of archs that constitute some type of x86 processor. Even Atom has different sibbling regarding their instruction pipeline. Nov 19 22:03:48 I saw core2 being used as an ARCH in poky, right? Nov 19 22:04:06 likewise: yes, I just pushed a switch to that Nov 19 22:04:23 So I could add "atom" but the "atom" namespace probably doesn't mean anything anymore after one year from now. Nov 19 22:05:20 likewise: Its a tricky question :/ Nov 19 22:06:24 saving file form thunderbird did not work, downloading mbox from patchwork did Nov 19 22:06:32 RP: I'll keep from adding a class now then. BTW, I was triggered by the links in this article: http://www.linux-mag.com/cache/7618/1.html Nov 19 22:09:11 RP: which is funny, because the GCC 4.4.2 docs don't mention atom for -mtune, but the Fedora release 12 announcement says "-march=i686 -mtune=atom"... Nov 19 22:09:52 if rday's guile-native patch still builds for me on F11, should I push? Nov 19 22:09:58 RP: so Fedora 12 might have a patched gcc 4.4.2 there. Nov 19 22:10:16 likewise: who knows :/ Nov 19 22:10:49 RP: I'll shut up and let the build talk for now :-) Nov 19 22:18:31 03Robert P. J. Day  07org.openembedded.dev * r9ffb647a36 10openembedded.git/recipes/guile/ (3 files in 2 dirs): Nov 19 22:18:31 guile-native: Add patch to inhibit generation of linemarkers from cpp. Nov 19 22:18:31 Add the "-P" option to inhibit generation of linemarkers in the output Nov 19 22:18:31 from the preprocessor. Nov 19 22:18:31 Signed-off-by: Robert P. J. Day Nov 19 22:22:14 I can't test that widely, hopefully it does not break anyone's builds Nov 19 22:34:47 likewise: yeah, atom support is new in gcc 4.5.0. if fedora has it in 4.4.2 then they must be applying a backport. Nov 19 22:35:05 * * OE Bug 5338 has been created by kevyn.alexandre.pare(AT)gmail.com Nov 19 22:35:07 * * Task failed : opkg-native_svn.bb Nov 19 22:35:09 * * http://bugs.openembedded.org/show_bug.cgi?id=5338 Nov 19 22:38:44 pb__: Any strong feelings against turning a large chunk of glibc-package.bbclass into a proper class? Nov 19 22:39:03 pb__: The objective would be to make it easier to package prebuilt toolchains Nov 19 22:39:35 RP: yeah, seems like a good idea. that would solve the eglibc problem as well to some extent. Nov 19 22:39:50 RP, you can do what ever you like as long as it doesn't break :) Nov 19 22:41:28 Crofton|work: You don't remember the days when we used to make proper changes, its so much more "stable" now... Nov 19 22:41:38 heh Nov 19 22:41:49 and how do you define "stable" :) Nov 19 22:42:08 Crofton|work: Compared to OE.dev four years ago Nov 19 22:42:09 we need the stable branch, and the glacial branch Nov 19 22:42:11 yeah Nov 19 22:42:12 * mwester 's ears perk up Nov 19 22:42:22 and the monotonically improving branch Nov 19 22:43:12 the audited branch :-) Nov 19 22:44:00 the people building on beta distros branch Nov 19 22:44:32 We had monotone, which was a sufficient barrior to entry to limit the number of contributors, though. Nov 19 22:47:17 :) Nov 19 22:49:36 I have another totally new arch (Altera NIOS) with a specific toolchain that is from a GIT'd non-upstream fork of gcc/binutils. The toolchain elements have the arch name in their recipe versions (like gcc-3.4.4-nios2). Is that an acceptable way to merge?? Nov 19 22:53:11 likewise: personally I would do it as "gcc-nios2-3.4.4", but it doesn't really matter either way. the basic principle is fine. Nov 19 23:05:12 is there a way to prevent sources pulled from an SVN server from being cached in a tarball? i'm doing some development and want to pull directly from the SVN server at each rebuild. Nov 19 23:06:25 I'd suggest using an external checkout and making a modified recipe (or using an amend.inc) that uses srctree.bbclass to build out of it, or do the work yourself.. easier than the fetch/unpack/patch cycle after every clean Nov 19 23:06:26 heh Nov 19 23:06:39 what about AUTO_REV? Nov 19 23:07:37 pb__: thanks for that suggestion, looks a bit neater indeed. Nov 19 23:15:24 how do I get 802.11n bitrates? I'm using "iwconfig wlan0 channel 149" and I can verify I'm in the 5GHz range, but my bitrates only go up to 54M Nov 20 00:18:42 kergoth: thanks for the suggestion. i was hoping there was something more out-of-the-box. :-) Nov 20 00:18:59 crofton: not familiar with that ... i'll read up in the manual. Nov 20 00:19:47 crofton: thanks for the suggestion! Nov 20 00:54:59 03Richard Purdie  07org.openembedded.dev * r04fcc4314b 10openembedded.git/recipes/libacpi/libacpi_0.2.bb: Nov 20 00:54:59 libacpi: Drop undeeded custom staging function Nov 20 00:54:59 Signed-off-by: Richard Purdie Nov 20 00:55:01 03Richard Purdie  07org.openembedded.dev * r7a880a7050 10openembedded.git/.gitignore: Nov 20 00:55:01 .gitignore: Ignore backup files (*~) Nov 20 00:55:04 Signed-off-by: Richard Purdie Nov 20 00:55:06 03Richard Purdie  07org.openembedded.dev * rdf62679798 10openembedded.git/recipes/perl/ (3 files): Nov 20 00:55:09 libxml-parser-perl: Set DEPENDS properly (from Poky) Nov 20 00:55:11 Signed-off-by: Richard Purdie Nov 20 00:55:13 03Richard Purdie  07org.openembedded.dev * r3176e14998 10openembedded.git/classes/packaged-staging.bbclass: Nov 20 00:55:16 packaged-staging.bbclass: Add method to disable packaged-staging from recipes Nov 20 00:55:18 Signed-off-by: Richard Purdie Nov 20 00:55:20 03Richard Purdie  07org.openembedded.dev * rb666b55230 10openembedded.git/recipes/glibc/ (18 files): Nov 20 00:55:23 glibc: Separate out core glibc packaging functionality into a class which can be reused by external toolchains (from Poky) Nov 20 00:55:27 Signed-off-by: Richard Purdie Nov 20 01:16:16 Crofton: I've done many searches and have come up short on the AUTO_REV spec. any pointers? Nov 20 01:19:31 kg4ysn: Try AUTOREV Nov 20 01:21:42 RP: That's it! Thanks so much! Nov 20 01:32:14 hmm didn't quite do it. still pulling out of the svn cache. weird. **** ENDING LOGGING AT Fri Nov 20 03:00:07 2009