**** BEGIN LOGGING AT Fri Mar 18 02:59:57 2011 Mar 18 06:32:44 03Martin Jansa  07master * re043f30dcf 10openembedded.git/recipes/gnutls/gnutls_2.10.4.bb: (log message trimmed) Mar 18 06:32:44 gnutls-2.10.4: add missing quote to PR Mar 18 06:32:44 * is something wrong with parser in bitbake master? IIRC we had Mar 18 06:32:44 parse exceptions before for similar typos Mar 18 06:32:44 * missing quote produces not so nice error like this Mar 18 06:32:45 NOTE: Running task 1010 of 1049 (ID: 31, /OE/dev/recipes/gnutls/gnutls_2.10.4.bb, do_setscene) Mar 18 06:32:46 NOTE: package gnutls-2.10.4-"r11.2: task do_setscene: Started Mar 18 06:33:52 gm Mar 18 06:34:43 gm Mar 18 06:38:28 how to workaround this: http://pastebin.com/Szf4Fuuc Mar 18 06:38:33 ? Mar 18 06:45:43 hi mickey|zzZZzz no phone stack, it's for industrial applications so I only have an application using AT commands to monitor network quality on one virtual serial port and ppp on an other and a sms "client" on the third one Mar 18 06:50:36 mickey|zzZZzz: btw as I've not studied phone stacks, do you think a phone stack could help in this usage while not adding to much dependecies ? Mar 18 08:02:10 good morning Mar 18 08:42:11 morning Mar 18 08:56:57 ant_work: hi Mar 18 08:59:53 hi mckoan Mar 18 10:46:15 hm hm shoud I make a libatomic-ops class Mar 18 10:53:11 what would that class do? Mar 18 10:55:21 would set the DEPENDS to all the arch'es its needed Mar 18 10:55:35 but for now its only 2 packages I know off using it Mar 18 10:55:39 pulse and cairo Mar 18 10:56:09 oh, right. yeah, I guess that could work. or alternatively make a dummy-libatomic-ops recipe which doesn't do anything, and set COMPATIBLE_HOST appropriately for it and the real package. Mar 18 11:35:14 hm hm with gcc-4.5 mips dont libatomic-op too Mar 18 11:35:18 +needs Mar 18 11:42:38 hi obi Mar 18 11:46:06 hi woglinde! Mar 18 11:58:22 03Paul Menzel  07master * ra36e1ddc2b 10openembedded.git/recipes/xfce-base/xfce4-session_4.6.1.bb: Mar 18 11:58:22 xfce4-session_4.6.1: fix typo s/ibxfcegui4/libxfcegui4/ Mar 18 11:58:22 This is a fix up for commit 7a92f740 [1] which was edited [2] before committing to fix some style issues introducing the typo. Mar 18 11:58:22 [1] http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=7a92f740433a3268faa5e3448671a24f3eb42884 Mar 18 11:58:22 [2] http://patches.openembedded.org/patch/1205/ Mar 18 11:58:22 Signed-off-by: Paul Menzel Mar 18 12:02:51 Tartarus, hi, I sent patches to support exopcslate machine to ml like 3 weeks ago, but I haven't got any response yet... you even fixed a bug using the patches. Could you review them and push them please? Mar 18 12:04:55 pespin: those? http://git.openembedded.org/cgit.cgi/openembedded/log/?qt=grep&q=exopc :) Mar 18 12:05:38 JaMa, yeah Mar 18 12:05:58 oh, they are applied? Mar 18 12:06:02 I misslooked it Mar 18 12:06:20 *g* Mar 18 12:09:00 hm. cgit looks a lot nicer than browsing a repo in trac... Mar 18 12:09:28 tasslehoff depends Mar 18 12:12:07 03Neil Jerram  07master * r9d21876bc9 10openembedded.git/recipes/freesmartphone/frameworkd_git.bb: Mar 18 12:12:07 frameworkd: add python-sqlite3 to RDEPENDS Mar 18 12:12:07 * Otherwise opimd doesn't work at runtime Mar 18 12:12:07 Signed-off-by: Martin Jansa Mar 18 12:12:16 03Lukas-David Gorris  07master * r0ce986d9e6 10openembedded.git/recipes/shr/shr-settings/htcleo/elementary.sh: Mar 18 12:12:16 shr-settings: add elementary.sh for htcleo Mar 18 12:12:16 * Based on GNUtoo's config for nexus one. Mar 18 12:12:16 Signed-off-by: Martin Jansa Mar 18 12:31:40 03Koen Kooi  07org.openembedded.dev * ra5c8965d77 10openembedded.git/conf/distro/angstrom-2010.x.conf: Mar 18 12:31:40 angstrom: copy parts of SHR blacklist Mar 18 12:31:40 Signed-off-by: Koen Kooi Mar 18 12:31:50 03Koen Kooi  07org.openembedded.dev * r5b28334152 10openembedded.git/recipes/qt4/qt4-embedded-gles_4.7.2.bb: Mar 18 12:31:50 qt4-embedded 4.7.2: add GLES2 recipe Mar 18 12:31:50 As with the 4.6.x version, this will only build if you don't have regular qt/e in staging. If you do, you will get QEGL:: link failures. Mar 18 12:31:50 Signed-off-by: Koen Kooi Mar 18 13:24:36 Any sheevaplug users of OE? Mar 18 13:25:22 Or, to be more specific, who would care if I altered the kernel defconfig for the sheevaplug to better suit SlugOS? Mar 18 13:26:15 * mwester-laptop finally got around to replacing the in-flash image on his Sheevaplug with SlugOS, and thinks some changes might make it considerably easier. Mar 18 16:05:29 ah, Angstrom blacklisted linux-hotplug, hotplug2 and hotplug-ng..."hotplug functionality is provided by udev" Mar 18 16:05:49 providers issue solved Mar 18 16:06:17 btw I found linux-hotplug is only called in task-base, for 2.4 kernels Mar 18 16:06:28 ant_work: few more fixes on ML... Mar 18 16:06:28 maybe we can obsolete it? Mar 18 16:06:39 yep, trying to follow :) Mar 18 16:07:25 bye Mar 18 16:07:38 have a nice weekend Mar 18 16:12:05 03Mark Hatle  07master * re736fa456d 10bitbake.git/lib/bb/ (cache.py runqueue.py): (log message trimmed) Mar 18 16:12:06 runqueue.py: Enable PSEUDO (fakeroot) before the fork Mar 18 16:12:06 PSEUDO when used as the fakeroot program is usually preloaded into memory, Mar 18 16:12:06 but disabled by default. The trigger for enabling it is a set of environment Mar 18 16:12:06 variables and a fork() or exec*() operation. Mar 18 16:12:06 We need to setup the environment, specifically PSEUDO_DISABLED=0, prior to Mar 18 16:12:07 the fork() so that python tasks can be run under PSEUDO control. Mar 18 17:03:12 03Chris Larson  07master * r9e9c75761e 10bitbake.git/lib/bb/build.py: Mar 18 17:03:12 build: add missing bit necessary for mhatle's fakeroot fix Mar 18 17:03:12 Signed-off-by: Chris Larson Mar 18 17:41:50 hi folks, can anyone help explain why I'd be getting a multiple providers issue for gdk-pixbuf-loader-png when compatibility-providers.conf sets PREFERRED_PROVIDER_gdk-pixbuf-loader-png ?= "gtk+"? Bitbake says: The PREFERRED_PROVIDER entries resulting in this conflict were: ['PREFERRED_PROVIDER_gdk-pixbuf-csource-native = gtk+-native', 'PREFERRED_PROVIDER_gtk+ = gtk+'] Mar 18 17:47:32 hbeck: there is a fix for this floating around on ml Mar 18 17:47:33 hbeck: both gtk+-native and gtk+ are indiciating that they will emit gdk-pixbuf-loader-* packages. normally, bitbake determines preferences about runtime like this implicitly, based upon gtk+-native and gtk+ being preferred build time. if, however, *both* gtk+-native and gtk+ are preferred with PREFERRED_PROVIDER, then the implicit runtime preference handling ends up the same for both, and it doesn't know what to do, hence the message Mar 18 17:47:44 hbeck: https://github.com/kergoth/oe-core/commit/02544c5 - not in oe yet Mar 18 17:48:09 kergoth: JaMa posted another patch which should not be needed after ur patch I guess Mar 18 17:48:23 yeah, i think that was a specific workaround for just gtk+ right? Mar 18 17:48:30 kergoth: yes Mar 18 17:48:41 can you reply to that mail and propose your fix instead Mar 18 17:48:52 you posted the fixes for oe-core Mar 18 17:49:02 and this one should go into both Mar 18 17:49:08 current oe as well as oe-core Mar 18 17:49:24 kergoth: thanks Mar 18 17:49:47 hbeck: you should be able to apply that patch locally to shut it up for now. np Mar 18 17:49:49 khem: k, will do Mar 18 17:49:57 erm, i should add to my todo list so i don't forget about it.. Mar 18 17:49:59 * kergoth does Mar 18 17:51:42 https://github.com/kergoth/oe-core/commit/8c6adce - not ideal, really, but thoughts on the concept? with basichash, the stamp contains the signature, so we never have to bump pr to get it to *rebuild*, so pr could go away entirely in favor of automatic PKGR handling ala srcrev Mar 18 17:52:39 means more rebuilds than today, but it'd be more reliable, since deps would always automatically be rebuilt when you change something Mar 18 17:53:23 ideally, we'd probably increment PKGR based on the actual metadata and files going into the package, rather than the recipe metadata going into the packaging task, but its similar in concept Mar 18 17:54:58 kergoth: hmmm so PR is now PKGR which is a hash Mar 18 17:56:05 pretty much. PR will only exist for packaging, since its not needed to handle rebuilds, and we can intelligently and automatically bump it when appropriate based on hashes Mar 18 17:56:08 will PKGR appear in final package names like PR does ? and will this hash be consistent if its part of Mar 18 17:56:24 ah ok Mar 18 17:56:25 kergoth: not familiar with github, looks nifty though. Is there a way to grab the changes it shows as a file to be used as patch? Mar 18 17:56:26 got it Mar 18 17:56:28 the hash won't be in the pkgr directly Mar 18 17:56:36 but it'll be stored in a db with the pkgr version number Mar 18 17:56:41 to compare against and bump when we need to Mar 18 17:56:41 kergoth yes I see hash is internal thing Mar 18 17:56:45 right Mar 18 17:56:49 which is for stamps Mar 18 17:57:03 and it also takes into account bumping PR Mar 18 17:57:08 which is cherry on top Mar 18 17:57:19 I mean manually bumping PR Mar 18 17:57:46 e.g. if I am crazy and I just want to force a rebuild and I just bump PR manually it will still do it right Mar 18 17:58:02 since PR is part of hash generation Mar 18 17:58:07 right now, no. remember that we track variable deps, so if a variable you change isn't *used*, it doesn't go into the signature Mar 18 17:58:17 but, we coudl explicitly force it to be part of the signatures if we wanted to Mar 18 17:58:26 if it isn't already.. hmm Mar 18 17:58:28 maybe it is, an d you're right Mar 18 17:58:30 not sure :) Mar 18 17:58:55 I think the concept looks good to me Mar 18 17:59:01 and patch too Mar 18 17:59:03 but yeah, we could easily do something to let you manually do it if you really wanted to, but i expect it wont often be necessary Mar 18 17:59:19 if i add 'echo foo' to do_install, the recipe is rebuilt and all its deps rebuilt, and the packages revisions get bumped Mar 18 17:59:21 at least with the above implementation Mar 18 17:59:25 so you expect a PR bump with some code change Mar 18 17:59:46 if you change a task or variable that's used by any task leading up to the task that saves sstate packages, it changes its signature Mar 18 18:00:00 all the vars used *and the task's deps' signatures* flow into a task's signature Mar 18 18:00:16 what I mean is only PR bump may not be enough trigger rebuild Mar 18 18:00:30 PR is used in packaging :) Mar 18 18:00:39 so I guess its under used category Mar 18 18:01:02 nono, in the above, the packaging uses PKGR instead of PR, and PKGR is automatic, so PR isn't used directly Mar 18 18:01:19 so if we wanted it to still flow into the signatures, just need to make sure its explicitly included Mar 18 18:01:32 not a big deal to do if we want to make sure that still works, if it doesn't already Mar 18 18:01:40 ok Mar 18 18:01:48 looks good to me Mar 18 18:02:08 the only downsides i see to this are avoiding unnecessary user upgrades, for one, which means changing the pkgr bumping to go by what actually goes into the package, rather than the do_package_write_ipk signature Mar 18 18:02:31 and of course we get a lot more rebuilds using hashes in the stamps, but 90% of the time that's not really a big deal, unless you're hacking on glibc or gcc or soemthing Mar 18 18:02:44 can always exclude the task you're working on from the sig temporarily or something, for development Mar 18 18:03:29 * kergoth thinks Mar 18 18:04:39 hbeck: erm, i'm actually not sure.. you'd expect there to be a 'raw' button, but either i'm blind or there isn't one. could always add the above repository to your oe git repository as a remote, and cherry-pick the change :) but its only a two-liner, you can always just edit native.bbclass to do it too :) Mar 18 18:05:20 kergoth: yes and we expect fewer changes to core components like gcc and friends Mar 18 18:05:56 khem: yeah, you'd hope so. Mar 18 18:07:18 i rather like the hash being in the stamp, makes the whole thing feel a bit less dangerous. no manual fiddling around. if you change something we track, we know it and things just rebuild for you. certainly better for the average user, i'd think Mar 18 18:07:23 lots of people forget to bump PR Mar 18 18:08:51 kergoth: yeah, doing it manually for now. Also noticing that your native.bbclass is missing 2 lines that are in the main currently: TOOLCHAIN_OPTIONS = "" and STAGING_DIR_JAVA = "${STAGING_DATADIR_JAVA_NATIVE}" Mar 18 18:09:33 hbeck: yeah, not too surprising, oe-core was based on poky, so there are still some differences that need to be synced up between them (there's a wiki page full of stuff we need to pull from oe into oe-core :) Mar 18 18:09:55 got it, not something to worry about then Mar 18 18:12:47 right. Mar 18 18:37:56 03Chris Larson  07master * r88f0d1db88 10bitbake.git/lib/bb/runqueue.py: Mar 18 18:37:56 runqueue: simplify fakeroot environment handling Mar 18 18:37:56 Signed-off-by: Chris Larson Mar 18 18:42:10 kergoth: it this fix the problem solves rpm issue Mar 18 18:42:33 latest two pushes to the oe bitbake fix the rpm issue with oe-core Mar 18 18:42:51 if you find it doesn't please add to the yocto project defect 890... Mar 18 19:46:35 03Koen Kooi  07org.openembedded.dev * rb610b316d4 10openembedded.git/recipes/qt4/qt4-x11-free-gles_4.7.2.bb: Mar 18 19:46:35 qt4-x11-free: fix up GLES recipe Mar 18 19:46:35 As with the 4.6.x version, this will only build if you don't have regular qt/x11 in staging. If you do, you will get QGL:: link failures. Mar 18 19:46:35 Signed-off-by: Koen Kooi Mar 18 21:28:22 re kergoth Mar 19 00:22:15 I think patch(1) was recently updated not to allow patches with leading ..'s (I remember I got a an update from Fedora recently)... Mar 19 00:22:21 now I get this from OE: Mar 19 00:22:37 ERROR: Error in executing python function in: /home/hollisb/work/system-builder/release-2010.2/openembedded/recipes/tcltk/tcl_8.5.8.bb Mar 19 00:22:40 Applying patch mips-tclstrtod.patch Mar 19 00:22:41 patch: **** rejecting target file name with ".." component: ../generic/tclStrToD.c Mar 19 00:28:13 03Graeme Gregory  07master * rb091590f91 10openembedded.git/classes/angstrom.bbclass: Mar 19 00:28:13 angstrom.bbclass : make message use DISTRO var Mar 19 00:28:13 Use the DISTRO variable for the name of the distro making this class Mar 19 00:28:13 distro neutral. Mar 19 00:28:13 Signed-off-by: Graeme Gregory Mar 19 00:30:43 fray: I guess you just worked around something similar in db Mar 19 00:30:55 fray: but shouldn't you have modified the patch file itself instead? Mar 19 00:31:22 03Graeme Gregory  07master * ra182828b78 10openembedded.git/recipes/linux/ (8 files in 5 dirs): Mar 19 00:31:22 linux-omap_2.6.38.bb : update to latest Mar 19 00:31:22 tmlind tree hasnt switch to 2.6.38 versioning yet, so this is still Mar 19 00:31:22 -rc8. Rebased the patches and added one to make SMC instruction compile Mar 19 00:31:22 and support XM rev C Mar 19 00:31:23 Signed-off-by: Graeme Gregory **** ENDING LOGGING AT Sat Mar 19 02:59:56 2011