**** BEGIN LOGGING AT Wed Apr 03 02:59:58 2013
Apr 03 04:03:44 <niteshnarayanlal> I was trying to make modifications in the existing package of core
Apr 03 04:04:00 <niteshnarayanlal> I had replaced the its tar file withing sources
Apr 03 04:04:22 <niteshnarayanlal> and then rerun bitbake
Apr 03 04:04:26 <niteshnarayanlal> but it was not built
Apr 03 04:04:41 <niteshnarayanlal> so do I have to build it seprately
Apr 03 07:15:04 <mckoan> good morning
Apr 03 07:35:23 <panda84kde> Hi everybody
Apr 03 07:39:24 <panda84kde> otavio: I can't see the gpu-updates patchwork bundle http://patches.openembedded.org/bundle/otavio/gpu-updates-20130401/ nor I see the patches merged. What happend to the patchwork bundle?
Apr 03 07:45:26 <panda84kde> Uh, it looks like patches are in, it's just github mirror is not already in sync.
Apr 03 08:00:50 <bluelightning> morning all
Apr 03 08:01:01 <erbo> morning
Apr 03 08:09:11 <mckoan> hi bluelightning, erbo, all
Apr 03 08:27:44 <Saur> bluelightning: Btw, regarding my problems with DISTRO_FEATURES yesterday. It turned out I had made the assignment in the wrong file (i.e., in the image recipe). It worked much better when I set it in local.conf...
Apr 03 08:41:20 <bluelightning> Saur: aha... mystery solved :)
Apr 03 08:41:40 <bluelightning> Saur: thanks, at least it wasn't an undiscovered bug
Apr 03 10:24:52 <mckoan> rburton: about xinput-calibrator...
Apr 03 10:24:59 <rburton> mckoan: hey
Apr 03 10:25:32 <mckoan> rburton: ;-)
Apr 03 10:25:36 <mckoan> rburton: dependency chain was: ['xinput-calibrator', 'xterm', 'libxaw', 'xmlto-native']
Apr 03 10:25:58 <mckoan> rburton: I would add them to meta-oe/recipes-graphics
Apr 03 10:26:01 <rburton> why does xi need xterm?
Apr 03 10:27:00 <JaMa> http://git.openembedded.org/meta-openembedded/commit/?id=bab6476691ba2a2d944ec814008f79e04a6a114a
Apr 03 10:27:25 <rburton> oe-core has two other terminals already
Apr 03 10:27:45 <mckoan> rburton, JaMa: fine thx I am changing the recipe
Apr 03 10:27:47 <rburton> and isn't there an alternatives thing for that?
Apr 03 10:28:44 <mckoan> rburton: hmmm I have to investigate that
Apr 03 10:29:15 <rburton> maybe not
Apr 03 10:29:38 <JaMa> rburton: there isn't VIRTUAL-RUNTIME_x-terminal for that
Apr 03 10:29:56 <JaMa> u-a can help on target but not with metadata
Apr 03 10:30:14 <mckoan> rburton: BTW after calibration the pinter goes crazy, probably there is a problem with xorg touch driver
Apr 03 10:30:23 <rburton> i was hoping that there was an alternatives for terminals, like debian. sadly not.
Apr 03 10:30:23 <mckoan> s/pinter/pointer
Apr 03 12:18:04 <otavio> panda84kde: yes; they're merged
Apr 03 12:18:20 <rburton> damnit pam
Apr 03 12:19:03 <panda84kde> otavio: yes, I've noticed. Thanks for the confirmation however
Apr 03 12:19:32 <otavio> panda84kde: you're welcome
Apr 03 12:19:55 <otavio> panda84kde: I am cooking two more patches to gpu as well
Apr 03 12:21:08 <panda84kde> otavio: which aspects do they touch?
Apr 03 12:25:35 <otavio> panda84kde: packaging
Apr 03 12:25:55 <otavio> panda84kde: and I hope for the last time
Apr 03 12:25:58 <otavio> lol
Apr 03 12:26:13 <panda84kde> otavio: is something broken / not working now?
Apr 03 12:28:13 <otavio> panda84kde: yes
Apr 03 12:28:17 <otavio> panda84kde: gst-gl
Apr 03 12:29:10 <otavio> panda84kde: and I fixed qt4 support  I think
Apr 03 15:37:08 <Sput> hmm. is there some nice way for cleaning unused/old work directories short of removing everything and starting from scratch?
Apr 03 15:37:25 <Sput> tmp/work takes up around 100GB here, I think I should clean that one up a bit :)
Apr 03 15:38:40 <walters> Sput, INHERIT += "rm_work"
Apr 03 15:38:46 <bluelightning> Sput: there is also scripts/cleanup-workdir ; I've not used it myself
Apr 03 15:38:59 <rburton> Sput: cleaning up is over-rated :)
Apr 03 15:39:01 <bluelightning> rm_work is probably a better option
Apr 03 15:39:01 <Sput> walters: yeah, but I would like to keep around the latest copy at least for certain packages
Apr 03 15:39:15 <Sput> bluelightning: aaah, just found that. I already had found sstate-cache-management, that's quite useful
Apr 03 15:39:30 <Sput> rburton: unless you are on an SSD :)
Apr 03 15:39:38 <rburton> Sput: that is true :)
Apr 03 15:39:58 <bluelightning> Sput: RM_WORK_EXCLUDE in master; or for older versions: http://lists.linuxtogo.org/pipermail/openembedded-core/2013-March/037579.html
Apr 03 15:40:29 <Sput> thx; I'll look into that
Apr 03 15:40:45 <Sput> first I'll try out cleanup-workdir and see what it does
Apr 03 15:41:01 <Sput> "Deleleting" :D
Apr 03 15:42:29 <Sput> looks like cleanup-workdir does exactly what I asked for, removing outdated workdirs while keeping current ones... I'll have a look at the other solution in case that makes more sense for me
Apr 03 15:45:52 <Sput> thanks for your help :)
Apr 03 16:36:19 <schramae> hi. does sb. know where /dev gets mounted on yocto 1.3 with udevd 164? i don't use an initramfs and it has no entry in fstab. /etc/init.d/udev does not do it as well, as /dev is already mounted when this is called. is there some in-kernel~ or /sbin/init magic? the mount shows up in dmesg at least...
Apr 03 18:09:31 <schramae> FTR: CONFIG_DEVTMPFS_MOUNT=y it is
Apr 03 18:20:41 <bluelightning> I feel we ought to document that somewhere but I'm not sure where we would...
Apr 03 18:26:34 <zeddii> khem. good news. I'm up and crashing qemumips + systemd. experimenting more.
Apr 03 18:26:40 <zeddii> qemumips64 to follow.
Apr 03 19:59:58 <Circuitsoft> Hello.
Apr 03 20:00:19 <Circuitsoft> I just did a "git pull" in my meta-intel checkout, and I'm now getting very strange build failures.
Apr 03 20:00:49 <Circuitsoft> I updated my recipe to point to emgd-1.16, and now when the kernel is built, it first merges in emgd-1.14, then emgd-1.16.
Apr 03 20:01:20 <Circuitsoft> The second merge fails due to the first merge, and I wind up with merge conflict markers in the code that the kernel is trying to build.
Apr 03 22:31:51 <Circuitsoft> Can I run devshell before do_patch on a kernel recipe?
Apr 03 22:32:33 <kergoth> not easily, but you can set PATCHRESOLVE = "user" which should make it automatically spawn a devshell if the patches fail to apply
Apr 03 22:34:06 <Circuitsoft> I have patches failing to apply, yet not being picked up by bitbake, resulting in an attempt to build the kernel with merge markers in the source.
Apr 03 22:34:18 <kergoth> ah, interesting
Apr 03 22:34:19 <Circuitsoft> One patch is being applied that shouldn't be, and I'm trying to track down where it's coming from.
Apr 03 22:34:32 <Circuitsoft> So, I want to run do_patch manually.
Apr 03 22:34:33 <kergoth> well, you could always hack it temporarily by modifying devshell.bbclass's addtask
Apr 03 22:45:49 <Circuitsoft> Any way to make it write run.do_patch but not actually run it?
Apr 03 22:46:18 <kergoth> the run script gets saved to a file all the time. you can always run it yourself from outsdie of bitbake..
Apr 03 22:47:01 <Circuitsoft> I'm in the devshell after do_validate_branches but before do_patch. I would like to see what do_patch would do without actually doing it.
Apr 03 22:48:05 <kergoth> do a bitbake -c patch at least once, re-enter the devshell, and run the run. sript
Apr 03 22:48:12 * kergoth shrugs
Apr 04 00:59:22 <Circuitsoft> I'm trying to update an ancient recipe, and I'm getting the following error:
Apr 04 00:59:53 <Circuitsoft> ERROR: ParseError at .../pyside/libshiboken_1.1.2.bb:28: unparsed line: 'STAGING_LIBDIR_NATIVE = ${STAGING_DIR}/${BUILD_SYS}${prefix}/lib'
Apr 04 01:00:06 <Circuitsoft> What was STAGING_DIR, and what would it be nowdays?
Apr 04 01:12:08 <kergoth> Circuitsoft: that recipe shouldn't be defining that variable at all.
Apr 04 01:12:24 <Circuitsoft> So, does that variable already exist?
Apr 04 01:13:29 <kergoth> bitbake -e is your friend
Apr 04 01:19:50 <Circuitsoft> What would cause CMAKE_AR-NOTFOUND ?
Apr 04 02:10:28 <Circuitsoft> How do I adjust a bitbake recipe to separate the build folder from the source folder?
**** ENDING LOGGING AT Thu Apr 04 02:59:58 2013