**** BEGIN LOGGING AT Mon Nov 28 02:59:57 2011 Nov 28 07:56:14 Hmm, Paul Eggleton is bluelighting, right? Nov 28 08:13:58 good morning Nov 28 08:33:53 mornin Nov 28 08:39:07 Jin^eLD: gm Nov 28 09:11:32 I just did a full build (rm -rf tmp), but Bitbake did not include kernel-module-libertas driver! Nov 28 09:12:16 I still have my linux-omap recipe, but other configuration was restored. Nov 28 09:12:49 My recipe (david-linux-omap) was not build and kernels were not mixed, this time. Nov 28 09:13:25 ./lib/modules/2.6.34/kernel/drivers/net/wireless/libertas/libertas_sdio.ko ./lib/modules/2.6.34/kernel/drivers/net/wireless/libertas/usb8xxx.ko Nov 28 09:13:31 Missing libertas.ko Nov 28 09:13:35 sakoman: ping Nov 28 09:14:33 Hmm... I have changes to module-init-tools-cross Nov 28 09:16:12 Probably that's it! Nov 28 10:41:23 hi all Nov 28 10:48:36 hi pb_ Nov 28 10:56:32 ericben: around? Nov 28 10:57:04 ericben: i just got your mail about the Qt issue ... Nov 28 11:03:42 otavio: hi. I trie to understand that for the last few hours but I need to be able to reproduce it (and from memory I fail to remember exactly the error message) Nov 28 11:03:58 ericben: sure ... Nov 28 11:04:39 ericben: the generated pkgconfig files has -L/usr/lib in Libs.private and this causes the user of host libraries as fallback Nov 28 11:05:53 RP__: how do you think it is better to address this issue? using SYSROOT env var from pkgconfig and dropping the expanded sysroot paths from it? Nov 28 11:06:30 otavio: do you have a simple example on how to trigger the problem so that I can reproduce it ? Nov 28 11:07:09 ericben: just build Qt and grep the generated pc files for '\-L/usr/lib' Nov 28 11:07:18 otavio: OK Nov 28 11:07:37 otavio: I think this may come from one sed in qt4.inc Nov 28 11:07:54 ericben: my problem was it ended up linking against a host lib and it took two days for me to get why it was segfaulting heh Nov 28 11:08:17 otavio: ok, this is with a cmake project ? Nov 28 11:08:27 ericben: no Nov 28 11:08:35 ericben: it failed with a qmake one Nov 28 11:09:08 ericben: it uses a static lib and then it got the libs.private options onto gcc command line, and then it made it link against host and fail Nov 28 11:09:14 otavio: ah ok so I should be able to reproduce it Nov 28 11:10:16 ericben: but you don't really need to reproduce it... as far as pc files are sane, we're fine Nov 28 11:10:36 ericben: and I can build a toolchain with a proposed fix and test here if need Nov 28 11:11:54 otavio: ok I launch a rebuild hope that won't break something else, will keep you updated Nov 28 11:12:07 otavio: in summary, yes Nov 28 11:12:07 ericben: awesome Nov 28 11:12:34 RP__: mind to explain to ericben what you want? he is looking at this now Nov 28 11:14:56 otavio: "what I want"? Nov 28 11:15:32 otavio: I just tried to explain to you how this should work (i.e. like the rest of the system), its not a personal thing Nov 28 11:16:47 RP__: ok; What I meant was is if you could tell ericben about this so we can fix it properly and avoid to have to work on that again in future Nov 28 11:17:15 ericben: The basic summary is that when we call pkg-config, we have 'export PKG_CONFIG_SYSROOT_DIR = "${STAGING_DIR_HOST}"' from bitbake.conf and this should ensure any paths returned from pkg-config have the appropriate suffix prepended Nov 28 11:17:35 ericben: in the target case we should only see paths like "/usr/lib" in the .pc files Nov 28 11:18:04 ericben: in the cross/native cases we see "/xxx/tmp/sysroot/xxx" paths since STAGING_DIR_HOST is / Nov 28 11:18:14 ericben: but we should never see them mixed together Nov 28 11:19:22 ericben: I never did establish was wasn't working in otavio's specific problem case but the .pc file he showed me was clearly broken as it had a mixture of these paths (and was for the target iirc so the non /usr/lib/ entries were incorrect) Nov 28 11:20:45 RP__: otavio : here is the .pc I get here : http://pastebin.com/ByGUKXv7 Nov 28 11:20:59 otavio: does yours looks like this ? Nov 28 11:21:29 ericben: yes; look at line 20 Nov 28 11:21:32 the problems is in Libs.private Nov 28 11:21:32 ericben: it is mixed Nov 28 11:21:37 otavio: yes Nov 28 11:22:05 that seems specific to qt .pc files Nov 28 11:30:03 otavio: I think I foudn the problem, build launched while going to the pool ;) Nov 28 11:30:24 ericben: I envy you now :P Nov 28 11:30:26 lol Nov 28 11:32:02 * pb_ stabs gcc Nov 28 11:32:26 seems that the library search paths are all busted if you have two MACHINEs sharing a TARGET_ARCH in a single build tree. Nov 28 11:33:22 pb_: That sounds worrying Nov 28 11:33:32 yeah, it is a bit suboptimal Nov 28 11:33:58 what seems to happen is that you end up with search paths to the MACHINE-specific sysroot encoded in the gcc driver binary (and/or its specs, I'm not quite sure which) Nov 28 11:34:30 but, since gcc itself is only namespaced by TARGET_ARCH, you end up with a random choice of MACHINE depending on what it happened to be set to when gcc was compiled. Nov 28 11:35:26 I think it generally doesn't matter since oe itself sets the appropriate paths on the compiler commandline, but it causes unexpected lossage if that fails to happen for some reason. Nov 28 11:40:11 ah yes, gcc.c embeds a default sysroot setting, see "target_system_root". Nov 28 11:41:53 on a different topic, does anybody have experience of persuading uclibc binaries to run on a glibc system? Nov 28 11:42:07 pb never tried Nov 28 11:42:09 I have a bunch of binary-only bits here which were, unfortunately, built against uclibc and that is not what we are using. Nov 28 11:42:53 but I have openjdk running again under uclibc Nov 28 11:42:55 and oe-core Nov 28 11:44:16 very good Nov 28 11:49:30 lucnh Nov 28 11:49:46 pb_: Perhaps we should set the inbuilt sysroot path for gcc to somewhere different Nov 28 11:50:06 pb_: We certainly assume that software is passing our flags in :/ Nov 28 11:54:39 yeah. it seems a little bit toxic to have the builtin sysroot path be somewhere that is sometimes right and sometimes wrong. Nov 28 11:55:13 I think we should either configure gcc with a builtin sysroot that is never right (so that it's obvious when you fail to pass --sysroot) or build it per MACHINE and get it to compile in the correct path (which would mean we could remove it from CFLAGS). Nov 28 12:02:56 woglinde, wow so java will come to oe-core, nice Nov 28 12:03:14 must one have some symlinks package to get the SDK to work? calling arm-angstrom-linux-gnueabi-gcc just gives me 'No such file or directory'. Nov 28 12:05:02 https://github.com/woglinde/meta-java Nov 28 13:02:44 tasslehoff: did you source /usr/local/angstrom-eglibc-x86_64-armv6-vfp/environment-setup-armv6-vfp-angstrom-linux-gnueabi (or the equivalent in your sdk) ? Nov 28 13:04:12 woglinde, ok thanks a lot Nov 28 13:29:02 ericben: I made an attempt at extracting the sdk to another folder in disk, since I consider adding it to version control. Nov 28 13:29:25 ericben: after putting it in /usr/local and sourcing, it executes Nov 28 13:29:41 why doesn't it when just invoked from the folder I have extracted to? Nov 28 13:30:17 maybe because of toolchain relocation issues? Nov 28 13:30:44 or maybe the script expects the toolchain to be at that place Nov 28 13:38:02 GNUtoo: must be something that expects it. twasn't that way in classic. Nov 28 13:38:24 but, I'm considering installing to /usr/local instead Nov 28 13:42:37 tasslehoff: that was the same behaviour under oe-classic, at least for angstrom sdk Nov 28 13:44:59 ericben: I spoke to Koen the other day about an issue I was having with getting Qt Creator to work with the qt embedded and he suggested I speak to since you already got it working. Nov 28 13:45:24 erickben: I am trying to cross compile my qt application in QT Creator on my host system to run it on my target system. However pointing Qt Creator to qmake located in linux-devkit/bin/qmake issues this message "Qt version is not properly installed, please run make install". It seems the way qt4-tools-sdk_4.7.2.bb is installing Qt files in a way that Qt Creator isn't happy with. Any tips on how you got this working? Nov 28 13:45:48 fcooper2: are you using qt Nov 28 13:45:51 4.7.2 ? Nov 28 13:46:23 ericben: Yes. And sourcing enviroment-setup and running qmake via command line works without a problem. Nov 28 13:46:35 fcooper2: so you are using oe-classic Nov 28 13:47:38 ericben: I believe so. This is being used within TI Arago SDK which I believe is using oe-classic recipes for qt. Nov 28 13:48:07 Are there a package for htpdate ? Nov 28 13:48:15 HTP (HTTP Time Protocol) Nov 28 13:49:26 fcooper2: this was fixed in oe commit 3b175b3421122c55d3acb1922d80b2caf15c9ccb so check if arago has this Nov 28 13:52:24 fcooper2: last time I tried (with oe-classic & qt 4.7.3 it was working fine) Nov 28 13:52:56 ericben: That commit is indeed included in arago's qt4-tools-sdk.inc file. In the file I see # make a symbolic link to mkspecs for compatibility with Nokia's SDK Nov 28 13:52:56 # and QTCreator which is what confused me in the first place. I assumed that this fix was addressing the issue but it didn't work for me. Nov 28 13:55:10 bluelightning: hi Nov 28 13:55:16 hi anarsoul Nov 28 13:55:29 ericben: Are you using Qt Creator on the target system or on your host system? Nov 28 13:55:32 bluelightning: here're some h1940 patches and updated config: http://devio.us/~anarsoul/h1940.28nov/ Nov 28 13:55:46 fcooper2: on the host system Nov 28 13:55:58 which version of qtcreator are you using ? Nov 28 13:56:23 bluelightning: these patches fix DMA issue with s3cmci (so DMA can be used with it), and with s3c24xx-i2s Nov 28 13:56:33 anarsoul: ok thanks... presumably this improves SD card access speed? Nov 28 13:56:46 nope, but it reduces CPU usage Nov 28 13:56:55 ok, cool Nov 28 13:57:07 I downloaded the latest version from Nokia 2.3.1 Nov 28 13:59:12 there's still isue with s3c24xx-i2s, it does not handle DMA errors properly Nov 28 14:00:03 anarsoul: what happens when a DMA error does occur? Nov 28 14:00:07 at the moment Nov 28 14:00:08 so mpg123 does not work for me (looks like it's not fast enough to provide sound data to alsa), but mplayer works Nov 28 14:00:14 bluelightning: nothing :) Nov 28 14:00:17 ok Nov 28 14:00:20 no sound Nov 28 14:00:39 no crashes, etc Nov 28 14:03:31 woglinde: cool, you pushed meta-java. Only the preferred version in local.conf and disabling angstrom-java.inc or did you keep it? Nov 28 14:03:38 bah, to late :) Nov 28 14:04:18 ericben: in classic I extracted the angstrom sdk to a folder on disk, and set CC to a gcc symlink that pointed to arm-angstrom.... and could compile without sourcing the environment setup Nov 28 14:04:46 tasslehoff: ok maybe I always used the environment script Nov 28 14:04:50 ericben: still, I should likely install like everyone else do :) Nov 28 14:05:10 ericben: the thought behind having it in VCS is to make it easier to reproduce release builds Nov 28 14:17:37 Hi, Is there an easy way to a use binary cross compiler rather than have OE build one to compile oe-core for a given target? Nov 28 14:18:00 (the binary gnueabi ARM toolchain that code sourcery provides for example) Nov 28 14:24:14 yes, you can use external tooclhains but the question is why? Nov 28 14:25:45 * kenws reads http://lists.linuxtogo.org/pipermail/openembedded-devel/2008-November/006946.html Nov 28 14:26:01 ant_work: To test the toolchain for example : ) Nov 28 14:29:21 testing toolchains? novel idea :) Nov 28 14:32:28 interesting - it looks likes one could set: TOOLCHAIN_PATH, TOOLCHAIN_TYPE, TOOLCHAIN_VENDOR, TOOLCHAIN_BRAND Nov 28 14:51:12 woglinde, will you add meta-java to http://www.openembedded.org/wiki/LayerIndex at some point? Nov 28 14:51:30 hi stefan_schmidt Nov 28 14:51:47 hi GNUtoo Nov 28 14:52:26 GNUtoo: meta-bug is already up and I'm working on meta-buglabs now. Testing meta-java as well. Nov 28 14:52:33 woglinde: cool, you pushed meta-java. Only the preferred version in local.conf and disabling angstrom-java.inc or did you keep it? Nov 28 14:53:05 stefan_schmidt, yes I run an xfce image on it Nov 28 14:53:13 built with openembedded-core Nov 28 14:53:23 GNUtoo: on bug20? Nov 28 14:53:24 but mplayer fails to compile somehow Nov 28 14:53:26 yes Nov 28 14:53:30 GNUtoo: nice Nov 28 14:53:37 I had to hand-fix dbus tough Nov 28 14:53:48 and it doesn't shut down well yet Nov 28 14:53:55 GNUtoo: hmm, there have been issues with mplayer for armv7a IIRC. Don't build it here normally Nov 28 14:53:55 (systemd...) Nov 28 14:54:11 yeah, systemd shutdown is broken here as well Nov 28 14:54:26 ok it's rather a library problem Nov 28 14:54:33 No idea how to fix this yet. Will look into it again when I have the other layers in place Nov 28 14:54:34 it doesn't find some XV symbols Nov 28 15:16:48 GNUtoo, woglinde: NOTE: package openjdk-6-jre-6b18-1.8.11-r11.0: task do_rm_work_all: Succeeded Nov 28 15:16:51 woglinde: nice job Nov 28 15:17:11 nice Nov 28 15:18:42 stefan_schmidt, nice :) Nov 28 15:20:52 Maybe this is a stupid question but how do I a clean up former builds? Nov 28 15:21:44 kenws: bitbake -ccleansstate TARGET Nov 28 15:21:45 I've tried `bitbake -c clean world` but a `bitbake core-image-minimal` doesn't seem to rebuild everything from scratch Nov 28 15:22:04 stefan_schmidt: thanks! Nov 28 15:22:22 kenws: np Nov 28 15:22:27 kenws: if you really want to clean out everything just rm -rf your tmpdir Nov 28 15:22:50 (or rather TMPDIR) Nov 28 15:23:33 bluelightning: yep, that's what I did earlier, but I thought there's probably some bitbake rule that does the trick Nov 28 15:23:52 kenws: not if you truly want to clean out everything Nov 28 15:24:06 it all depends on what you're trying to achieve Nov 28 15:24:13 ok : ) Nov 28 15:24:58 bluelightning: I'm trying to (ex)change the toolchain and therefore want to rebuild the minimal image from scratch using the external toolchain Nov 28 15:25:25 kenws: right, I think that probably qualifies as something where you'd just want to delete everything Nov 28 15:26:59 you'd probably want to delete the sstate-cache, although you should be able to speed up the next build with no ill effect by just deleting the non-native cache files Nov 28 15:27:54 bluelightning: so, you're suggesting `rm -r sstate-cache tmp-eglibc` prior the rebuild? Nov 28 15:28:28 you want tmp as well, but yes Nov 28 15:30:32 hm, there is no tmp dir - strange. thedefault should be ${TOPDIR}/tmp Nov 28 15:30:42 I definitely want to keep the downloads dir : ) Nov 28 15:32:41 has anyone used a USB 2.0 device on an atmel board with the at91_ohci driver? as far as I can tell ohci only supports USB 1.0 Nov 28 15:32:43 It looks like my "tmp" dir is the "tmp-eglibc" directory. Nov 28 15:48:17 woglinde: I had two small problems with the classpath recipe. First the LICENSE had no LIC_CHECKSUM and second QA erroring out because of so links Nov 28 15:48:39 woglinde: Skipping this error works here as a workaround: INSANE_SKIP_${PN} = "dev-so" Nov 28 15:49:15 but better to fix packaging if .so is not really needed Nov 28 15:49:52 JaMa|Off: sure, needs real fixing. Just as a workaround right now. Nov 28 17:10:18 Anyone know the fix for this (error during bitbake -c devshell) : (gnome-terminal:32371): GLib-GIO-CRITICAL **: Settings schema 'org.gnome.system.proxy' is not installed Nov 28 17:10:39 I know I can set TERMCMD and use xterm, but I'd really like to use gnome-terminal Nov 28 17:11:42 this may be the actual error: ERROR:terminal-app.c:1450:terminal_app_init: assertion failed: (app->system_font_desc != NULL) Nov 28 17:22:25 awozniak: is that error happening on target ? Nov 28 17:22:35 ah devshell Nov 28 17:24:58 I think problem could be that schema does not exist which it is tryng to set Nov 28 17:25:23 this may be a more ubuntu problem; sudo apt-get --reinstall install libgdk-pixbuf2.0-0 fails with an error: E: Internal Error, No file name for libgdk-pixbuf2.0-0 Nov 28 17:25:34 I think either install the schema on your host Nov 28 17:25:40 yes its 100% host problem Nov 28 17:49:44 otavio: I just sent you a patch, please try it and tell me if that fix the problem Nov 28 17:50:04 ka6sox: hi, is it possible for us to remove edit restrictions from the oe wiki? http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-November/036497.html Nov 28 17:50:28 ericben: awesome Nov 28 17:57:42 ericben: i am finishing a build and will give it a try Nov 28 18:01:51 bluelightning: spamming is still a problem Nov 28 18:02:12 khem: we have a captcha now, we did not have that before the restrictions were enacted Nov 28 18:02:19 bluelightning: although I dont know if we ever opened it up widely after introducin captcha Nov 28 18:02:30 right Nov 28 18:05:19 bluelightning: I think only registration must be regulated now. Edits should be as usual arent they Nov 28 18:05:55 khem: berhard can't edit his own user page, so I would assume not... Nov 28 18:06:23 hmmm thats something should not happen Nov 28 18:06:36 I thought it was restricted only for registration now Nov 28 18:06:59 ka6sox was travelling hope to catch him later today Nov 28 18:07:04 I will let him know Nov 28 18:07:31 probably hasn't helped documentation contributions... Nov 28 18:11:25 actually there are registration span that hits quite a bit Nov 28 18:11:35 I see that problem for patchwork too Nov 28 18:48:10 khem: I am merging youand & mine libtool commits, why are you replacing PR = r4 with PR = ${INC_PR}.0 ? Nov 28 19:02:24 nitink: since we have multiple recipes using common header Nov 28 19:02:57 nitink: btw. I have those patches rebased on top of what RP__ committed to libtool Nov 28 19:03:08 I can push those to the same branch if that will be useful for you Nov 28 19:03:19 khem: cool yes that would be useful Nov 28 19:08:49 What are you guys working on wrt libtool, out of curiosity? Nov 28 19:09:28 kergoth: update to 2.4.2 Nov 28 19:09:33 ah, cool Nov 28 19:09:47 kergoth: upstream has take couple of my fixes :) Nov 28 19:09:52 nice. Nov 28 19:09:57 kergoth: btw. regarding chair Nov 28 19:10:01 that's always great to see. we need to do a better job at that Nov 28 19:10:03 my office chair is same Nov 28 19:10:13 as we were talking about other day Nov 28 19:10:57 which one was that again? I was researching a pile of them :) I ended up picking up an Embody at the store yesterday, wanted to take advantage of the 15% off sale on herman miller right now Nov 28 19:13:54 stupid computer logged me off Nov 28 19:14:02 hehe Nov 28 19:14:03 kergoth: yes herman miller Nov 28 19:14:06 go for it Nov 28 19:14:10 its really nice one Nov 28 19:14:21 i went to a store and sat in a few of them. I don't see why so many people love the aeron Nov 28 19:14:32 i mean, it was fairly comfortable really, but there are too damn many adjustments to make Nov 28 19:14:43 and its awfully stiff, doesn't flex or move at all with you the way the mirra and embody do Nov 28 19:14:53 anyway :) Nov 28 19:15:11 herman miller I have has haudralics in it :) Nov 28 19:15:33 hydraulics Nov 28 19:16:09 kergoth: mine is Aeron Nov 28 19:16:26 ah, cool Nov 28 19:16:37 as long as you get it adjusted right :) Nov 28 19:17:44 kergoth: correct. I like the stiffness Nov 28 19:18:09 kergoth: but embody looks nice too. Havent sat on one so dont know the difference Nov 28 19:18:15 all the expensive chairs are so much better than the cheap ones that the differences between them are probably minor by comparison :) Nov 28 19:19:32 could be. Nov 28 19:19:40 * kergoth pokes at a panda build from meta-ti Nov 28 19:20:00 but I guess they do have some notable things amongst aeron and embody Nov 28 19:20:11 linux-omap4 apparently requires lzop, but it doesn't actually depend on it, afaict Nov 28 19:20:35 khem: apparently they designed the embody expecting it to replace the aeron, but it didn't work, too many people prefer the aeron for a variety of reasons, so now they're both around Nov 28 19:20:35 kergoth: isnt lzo optional in kernel Nov 28 19:20:56 hmm, good point, might have to make it obey the defconfig Nov 28 20:14:26 wonder if koen would accept a patch to dep on lzop-native if CONFIG_KERNEL_LZO is defined in file://defconfig Nov 28 20:14:32 would think so Nov 28 20:14:49 * kergoth cleans it up Nov 28 20:21:54 yes that a sane change imp Nov 28 20:21:56 imo Nov 28 20:22:25 k, thanks Nov 28 20:24:58 does anyone know why this message might be occuring: Nov 28 20:24:59 bootlogd: cannot allocate pseudo tty: No such file or directory Nov 28 20:25:03 just in general... Nov 28 20:25:18 /dev/pts not mounted? Nov 28 20:27:55 msm, I think I had the same message Nov 28 20:28:04 I'll look in my serial console if it still appear Nov 28 20:28:12 re-doing rootfs currently Nov 28 20:29:34 msm: variation on kergoth's question: did you create a mount point for /dev/pts? Nov 28 20:29:49 no Nov 28 20:29:51 well Nov 28 20:29:59 let's just say im running fine on real hardware Nov 28 20:30:08 there are people running on something "else" Nov 28 20:30:21 and get that message Nov 28 20:30:30 so maybe - udev is not mounting /dev/pts? Nov 28 20:30:33 msm, something else than what? Nov 28 20:30:37 something along those lines? Nov 28 20:31:00 yes we use devtmpfs Nov 28 20:31:01 GNUtoo: hardware emulator for instance - who knows what crap is interfering with normal operation Nov 28 20:31:25 msm: udev is hardware specific sometimes something else could be the problem Nov 28 20:31:29 you mean qemu,or hardware emulator for creating SOCs? Nov 28 20:31:34 basically Nov 28 20:32:45 I guess qemu, because other kinds of emulator are unlikely Nov 28 20:35:03 GNUtoo: no semiconductor companies have emulators too Nov 28 20:35:20 I know but they costs are outrageous Nov 28 20:35:25 and they are much rich featured in terms of emulation Nov 28 20:35:34 well not if you work for the semi Nov 28 20:35:49 I saw the video of the talk of porting Linux on unreleased SOC btw Nov 28 20:36:59 GNUtoo: well… no comment =) Nov 28 20:37:04 msm: is this emulator using some known machine conf or different that the hardware you said its working ok on Nov 28 20:37:15 khem: slightly different Nov 28 20:37:46 msm: I would suggest to look at the differences since it works on one hardware it could be just a kernel config or some such Nov 28 20:40:07 same kernel and rfs work though Nov 28 20:40:14 some minor changes in u-boot Nov 28 20:41:17 hmmm so .viminfo file was not writable now I see why my vim was crazy on this box Nov 28 20:47:32 Has anyone came across OPTION_EGLIBC_NSSWITCH_FIXED_CONFIG variable left unset error when running MACHINE=am37x-evm bitbake -b eglibc_2.12.bb? Copy of the log is located at http://pastebin.com/LUtqA6Vn I see several posts on the OE forums with no response to the posts. Nov 28 20:56:11 fcooper: this is because OPTION_EGLIBC_NSSWITCH is not set Nov 28 20:56:36 in this case it wants that config options OPTION_EGLIBC_NSSWITCH_FIXED_CONFIG and OPTION_EGLIBC_NSSWITCH_FIXED_FUNCTIONS are explicitly set Nov 28 21:04:04 khem, ping? Nov 28 21:04:47 ka6sox: hey Nov 28 21:05:09 hiya, remove restrictions? no way... Nov 28 21:05:14 ka6sox: is there any reason to keep the noose tight on wiki Nov 28 21:05:16 remove them for a user? sure! Nov 28 21:05:33 ok. I think we can keep the restrictions on new users Nov 28 21:05:38 registering Nov 28 21:05:39 yes, wikispam...I have NO time to keep up with it. Nov 28 21:05:59 but I think for registered users it should be made business as usual Nov 28 21:06:01 they register 100's per day Nov 28 21:06:11 shiela45 Nov 28 21:06:14 bob87 Nov 28 21:06:24 isnt there a captcha for registering ? Nov 28 21:07:00 the spammers create usernames with real people and then spam with the robot after they get "approved" Nov 28 21:07:07 NO automated system will catch that. Nov 28 21:07:36 so unless you want your wiki to be overrun with spam then its not doable. Nov 28 21:07:58 I have given enough people admin rights to promote users that they *know* are not spammers :D Nov 28 21:08:27 hmm for registering there should be a captcha too isnt it Nov 28 21:08:31 how do they overcome that Nov 28 21:08:48 because I don't allow "autopromotion" Nov 28 21:09:14 just because you can register properly does NOT give you access to edit/create/remove Nov 28 21:09:40 register properly, talk to one of our admins about promotion... Nov 28 21:09:41 khem: I guess I don't understand what the solution is. I tried adding GLIBC_EXTRA_OECONF += "OPTION_EGLIBC_NSSWITCH_FIXED_CONFIG OPTION_EGLIBC_NSSWITCH_FIXED_FUNCTIONS" to the recipe but I still got the same error. Was I suppose to be adding this somewhere else? Nov 28 21:09:50 then get promoted. Nov 28 21:10:32 no automagic....(now the board can override me on this and I'll be glad to back out of trying to keep your wiki free as much as possible of spam. Nov 28 21:10:34 ka6sox: ok Nov 28 21:10:35 ) Nov 28 21:10:47 ka6sox: but we should make it possible for registered users to edit as it used to be Nov 28 21:10:52 no Nov 28 21:11:01 not unless promoted by a live ADMIN. Nov 28 21:11:10 no automagic promotion Nov 28 21:11:43 ok. so a new user registers second step is someone promotes him to edit the wiki Nov 28 21:11:55 is it then normal for him/her to edit after promotion Nov 28 21:11:59 yes Nov 28 21:12:07 fcooper: is it with oe-core ? Nov 28 21:12:43 fcooper: it seems to be happening with aarago which I guess is based on oe classic Nov 28 21:12:52 khem, if I have a username and someone who we know can say "they pass the turing test and are someone who can contribute to this" then we can promote them. Nov 28 21:13:23 anything automagic will lead to NOTHING but an overrun wiki with Viagra Spam and other things. Nov 28 21:13:31 khem: Yes it is with oe-core. Nov 28 21:13:42 ka6sox: it would be nice if there was a way for us to promote the users who have contributed in past Nov 28 21:13:53 barring if there are spam pages still Nov 28 21:14:22 we could do that...I just need more time to be able to find those users. Nov 28 21:14:50 so if I knew what user bernhard is on the wiki I could promote him right away... Nov 28 21:15:01 but wholesale? recipe for disaster. Nov 28 21:16:02 agreed Nov 28 21:16:10 fcooper: hmmm Nov 28 21:16:28 fcooper: what changes did you make to eglibc config and/or DISTRO_FEATURES Nov 28 21:17:00 ka6sox: I think its worth documenting the process for getting wiki access on wiki Nov 28 21:17:11 so people can be directed to it Nov 28 21:17:17 right now there is some confusion Nov 28 21:17:29 and expectation is that now with captcha everything should be hunky dory Nov 28 21:17:39 which seems not to be the case as you put it Nov 28 21:17:45 its not Nov 28 21:17:47 sorry... Nov 28 21:17:57 captcha fails everytime with the way the spammers work. Nov 28 21:18:00 thats fine, we just then need to document it in wiki Nov 28 21:18:25 * khem SIGFOOD Nov 28 21:20:58 khem: eglibc config? Is that something within the eglibc_2.12.bb recipe? If so the only changes I have made was adding GLIBC_EXTRA_OECONF += "OPTION_EGLIBC_NSSWITCH_FIXED_CONFIG OPTION_EGLIBC_NSSWITCH_FIXED_FUNCTIONS" and changing the SRCREV to SRCREV="13230". I don't know anything about DISTRO_FEATURES so OI doubt that I changed it. Nov 28 21:28:37 fcooper: ok bitbake -e eglibc >& prep.txt and paste prep.txt somewhere please Nov 28 21:42:03 khem: http://pastebin.com/JcbgY2mq contains the text from prep.txt Nov 28 21:56:40 fcooper: ok so your build is NOT based on oe-core btw. Nov 28 21:56:49 fcooper: can you try this fix instead http://pastebin.com/YSZ96LbF Nov 28 21:56:58 fcooper: and rebuild eglibc Nov 28 22:10:29 khem: The compiling still failed: http://pastebin.com/HiKdrv6M I however did MACHINE=am37x-evm bitbake -b eglibc_2.12.bb -c clean and then MACHINE=am37x-evm bitbake -b eglibc_2.12.bb. I am trying now using just MACHINE=am37x-evm bitbake eglibc -c clean and MACHINE=am37x-evm bitbake eglibc to see if it makes a difference. I doubt it will but figured I just try it out. Nov 28 22:20:28 what recipe handles: tmp/sysroots/${MACHINE}-tcbootstrap/ Nov 28 22:21:54 msm: eglibc-initial Nov 28 22:22:13 fcooper: hmmm show me bitbake -e output after patching please Nov 28 22:22:32 msm: and also uclibc-initial if you care Nov 28 22:23:01 khem: i found a problem Nov 28 22:23:18 khem: my kernel headers are pointing to a broken symlink Nov 28 22:23:29 khem: when reusing cache Nov 28 22:23:47 anyone know an example recipe that needs to fix symlinks for things like this? Nov 28 22:24:35 khem, should I contact bluelightning about getting bernhard access? Nov 28 22:25:13 e.g.: /home/mattsm/git/poky/build_p4080ds_release/tmp/sysroots/p4080ds-tcbootstrap/usr/include/linux: broken symbolic link to `../../../..//sysroots/p3060qds/usr/include/linux' Nov 28 22:26:01 ka6sox: no, just elevate him now that we know he is genuine Nov 28 22:26:03 user Nov 28 22:26:38 msm: what needs fixing there Nov 28 22:26:59 msm: level ? Nov 28 22:27:10 what is his username? Nov 28 22:27:29 do_install step in eglibc Nov 28 22:27:41 it's making symlinks to linux,asm,asm-generic Nov 28 22:28:00 works fine when fully building Nov 28 22:28:04 but it breaks sstate-cache Nov 28 22:28:11 khem, promoted Nov 28 22:28:12 i'd like to repair these symlinks Nov 28 22:28:21 ka6sox: and let him know Nov 28 22:28:22 btw..you have the power to do this as well. Nov 28 22:28:33 msm: in my case they are absolute Nov 28 22:28:43 msm: so I wonder how do u get them relative Nov 28 22:28:57 ok Nov 28 22:29:16 khem: abolsute would still not work... Nov 28 22:30:48 msm: ok you can fix it in recipes-core/eglibc/eglibc-initial.inc Nov 28 22:30:55 do_install step Nov 28 22:31:08 but when you are at it please fix uclibc-initial too Nov 28 22:31:32 # add links to linux-libc-headers: gcc-{cross,crossdk}-intermediate need this. Nov 28 22:31:35 for t in linux asm asm-generic; do Nov 28 22:31:38 ln -s ${STAGING_DIR_TARGET}${includedir}/$t ${D}${includedir}/ Nov 28 22:31:41 done Nov 28 22:31:44 this is the piece you need to fix Nov 28 22:31:48 do u want to make them relative ? Nov 28 22:32:16 yes Nov 28 22:32:21 mine is relative? Nov 28 22:32:27 seems so Nov 28 22:32:36 as you pasted Nov 28 22:32:42 /home/mattsm/git/poky/build_p4080ds_release/tmp/sysroots/p4080ds-tcbootstrap/usr/include/linux: broken symbolic link to `../../../..//sysroots/p3060qds/usr/include/linux' Nov 28 22:32:45 right Nov 28 22:33:02 these symlinks point to non-existant directories in the cache case Nov 28 22:33:26 hmm Nov 28 22:33:50 Tartarus, bernhard has access to work on the wiki now. Nov 28 22:34:10 ka6sox: reply to the email thread Nov 28 22:34:19 khem: easier fix seems to be just to copy the kernel header Nov 28 22:34:26 msm: hmm that indirection level seems skewed Nov 28 22:36:24 khem: http://pastebin.com/ADQcgzVZ This is for MACHINE=am37x-evm bitbake -e -b eglibc_2.12.bb >& patch.txt Nov 28 22:37:42 fcooper: how did u add the patch I gave you Nov 28 22:37:49 fcooper: I dont see it in SRC_URI Nov 28 22:38:09 khem, sent Nov 28 22:38:09 khem: http://pastebin.com/Fj8K6sWr This is when I used MACHINE=am37x-evm bitbake -e eglibc >& patch2.txt It is pretty weird that I get two completely different errors. Nov 28 22:39:32 I didn't even think about using the SRC_URI. I copied the patch into a txt file and ran "git apply eglibc.patch" Nov 28 22:40:29 fcooper: never mind I see the patch is applied Nov 28 22:40:59 khem: the cache works if I'm using the p3060qds $machine that is referenced in the symlink… so it seems the actual issue is the broken symlinking Nov 28 22:41:20 khem: err, wait... Nov 28 22:41:23 fcooper: as I see PR value did not get properly expanded in your case Nov 28 22:41:32 khem: pre-typed that… it's almost done testing Nov 28 22:42:29 fcooper: /home/franklin/git_projects/bitbake/arago-tmp/work/armv7a-arago-linux-gnueabi/eglibc-1.0-r0/eglibc-1.0/nss/ does this path exist Nov 28 22:42:53 No Nov 28 22:43:12 msm: yes although I am vary that this cross sysroot referencing through symlinks might be not ok Nov 28 22:43:27 copying might be better Nov 28 22:43:40 fcooper: thats the next problem Nov 28 22:44:13 fcooper: can you do bitbake -cclean -b eglibc_2.12.bb and then bitbake eglibc Nov 28 22:44:27 fcooper: I want to make sure that reparse happenss Nov 28 22:44:36 khem: i'll make a patch to copy and see what feedback we get Nov 28 22:44:57 msm: how big is linux/ dir Nov 28 22:47:43 3.4mb Nov 28 22:48:09 3.7M actually Nov 28 22:48:18 its much better than having cache not working for me at least Nov 28 22:48:39 khem: I get the same error as before http://pastebin.com/Fj8K6sWr Nov 28 22:48:46 khem: should I add Nov 28 22:49:01 do_install[vardeps] += "virtual/kernel:do_sysroot_populate" Nov 28 22:49:13 fcooper: ok what does bitbake -e eglibc | grep "^S=" give you Nov 28 22:49:14 since this step not locks eglibc to a specific kernel version? Nov 28 22:49:19 this seems like overkill... Nov 28 22:49:45 fcooper: without scrolling up too far, you did warn folks this is arago right? :) Nov 28 22:50:00 Tartarus: yes I figured its aarago Nov 28 22:50:14 Tartarus: but problem was in eglibc anyway which I have fixed Nov 28 22:50:29 k, thanks khem Nov 28 22:50:30 Tartarus: I will post that patch to ml for 2011.03-maintenance branch Nov 28 22:50:43 sounds good Nov 28 22:50:59 Tartarus: problem is that now I am trying to verify and there might be arago'ness now biting Nov 28 22:54:06 fcooper: S seems to be populated ok Nov 28 22:54:08 # S=${WORKDIR}/${EGLIBC_BRANCH}/libc Nov 28 22:54:08 S="/home/franklin/git_projects/bitbake/arago-tmp/work/armv7a-arago-linux-gnueabi/eglibc-2.12-r21.12+svnr13230/eglibc-2_12/libc" Nov 28 22:54:19 khem: I am not sure if this makes a difference but initially when I first was running bitbake eglibc_2.12.bb I was getting an entirely different error. I looked at the OE git and saw that the recipe was slightly different. It had the SRCREV set to 13230 which I made the change in my local recipe now. Could this be the underlining issue? Nov 28 22:54:45 *underlying Nov 28 22:55:24 dont think so Nov 28 22:55:47 issue is that when evaluating S in the patch I gave you it flunks PR and PV Nov 28 22:56:03 OPTION_EGLIBC_NSSWITCH_FIXED_CONFIG = /home/franklin/git_projects/bitbake/arago-tmp/work/armv7a-arago-linux-gnueabi/eglibc-1.0-r0/eglibc-1.0/nss/nsswitch.conf Nov 28 23:16:10 khem: There is a nsswitch.conf located at /home/franklin/git_projects/bitbake/arago-tmp/work/armv7a-arago-linux-gnueabi/eglibc-2.12-r21.12+svnr13230/eglibc-2_12/libc/nss/ Nov 28 23:16:16 fcooper: Nov 28 23:16:35 yes thats what I expected it to get when I used S Nov 28 23:16:47 Tartarus: whats recommended bitbake version for 2011.03 branch Nov 28 23:17:11 khem: 1.10.x Nov 28 23:17:33 been muddling with 1.12 :) thx denix Nov 28 23:18:05 fcooper: is that regular un-modified eglibc? it worked for me Nov 28 23:19:08 fcooper: btw, any specific reason to re-build eglibc at all? as we normally use pre-built binary toolchain in our products... Nov 28 23:19:36 denix: this is a modified eglibc file. I changed the SRCREV to SRCREV="13230". I also applied the patch that khem sent me: http://pastebin.com/YSZ96LbF Nov 28 23:20:21 fcooper: I see. what's the specific feature you are looking from 13230 rev? Nov 28 23:21:00 denix: I get ${@oe.utils.ifelse(bool(d.getVar('MACHINE', True)), '${MACHINE}', 'BASE_PACKAGE_ARCH')} Nov 28 23:21:03 ERROR: EOL while scanning string literal (MACHINE_ARCH, line 1) while parsing /home/kraj/work/oe/openembedded/recipes/webkit/arora_0.10.2.bb Nov 28 23:21:07 flood of those Nov 28 23:21:28 khem: those mean something referenced a var in a python snippet using {} which was undefined Nov 28 23:21:30 denix: I am trying trying to run MACHINE=am37x-evm bitbake nano -v -D. Based on your tutorial from Arago Projects and modifying local.conf to have the TOOLCHAIN set to arago. I came across several errors trying to build nano and eglibc is the latest recipe that bitbake nano has failed on. Nov 28 23:23:09 fcooper: well, something is bad in the configs, as it shouldn't even go building eglibc with the standard arago setup, as we use pre-built binary toolchain by default. unless you specifically requested internal toolchain built from sources... Nov 28 23:24:09 khem: is that oe-classic maintenance and it fails in arora recipe? Nov 28 23:24:52 denix: My PATH is set to /home/franklin/git_projects/bitbake/arago-bitbake/bin/:/home/franklin/git_projects/bitbake/arago-utils/:/home/franklin/ti-sdk-am37x-evm-05.03.01.00/linux-devkit/bin/:/home/franklin/ccs/ccsv5/eclipse/jre/bin:/home/franklin/ccs/ccsv5/eclipse/jre/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games. I am using the toolchain from with the am37x evm. Nov 28 23:26:47 denix: *am37x evm 5.03.01 SDK. Nov 28 23:30:27 fcooper: I see. Nov 28 23:33:47 fcooper: I also see couple of your messages from yesterday to the arago list held for moderation... I'll check those and see what the original issue is - you don't need to patch or even re-build eglibc in your setup... Nov 28 23:34:40 khem: so, for the newer srcrev of eglibc, we need your patch in the maintenance branch, correct? Nov 28 23:35:03 denix: Alright denix that would be great. Please let me know. Nov 28 23:36:27 denix: yes, but that patch does not work yet Nov 28 23:36:53 bitbake does not know PR and PV when the S is asked for Nov 28 23:36:59 so it evaluated that wrongly Nov 28 23:37:13 that works ok with oe-core but not oe classic Nov 28 23:37:40 khem and denix: Thanks for you help. My laptop is about to die but I will be back on tomorrow. Nov 28 23:40:27 khem: I see, thanks. I was building srcrev=12323 and it works fine for us for now - I'll work with fcooper to rootcause his issue. Nov 28 23:48:02 fcooper: ok I think I have the fixed version Nov 28 23:48:06 fcooper: try it please Nov 28 23:48:48 fcooper: http://pastebin.com/YPwSXwyF Nov 28 23:49:21 I have sent the patch to ml too Nov 29 01:11:36 ericben: built it here but didn't test the sdk; will do tomorrow **** ENDING LOGGING AT Tue Nov 29 02:59:57 2011