**** BEGIN LOGGING AT Wed Feb 16 02:59:57 2011 Feb 16 09:58:45 I cannot compile shr-project image ^( Feb 16 09:59:20 shr-testing and shr-unstable fails with errors Feb 16 09:59:59 is shr-project compilable at th end of all? Feb 16 10:00:22 Or it is because of my mistake(s)? Feb 16 11:51:14 shade-khv1: for me shr-testing builds fine, shr-unstable can be broken from time to time Feb 16 12:20:33 Heiner i have numerous "ecore.vapi:225.16-225.19: warning: deprecated syntax, use `unowned` modifier" errors while building shr-testing Feb 16 12:23:25 and then i have " error: 'void' not supported as parameter type public static delegate void FreeCb(Rbtree node, void data);" Feb 16 12:23:56 really, how void could be an argument? Feb 16 12:27:16 while googling i found log _very_ simulat to my case Feb 16 12:27:18 http://tinderbox.openembedded.net/public/logs/task/15190703.txt Feb 16 12:35:08 i had detemined that this void error apperas in eina.vapi file. What is *.vapi? Is it written or automatically generated? Feb 16 12:45:56 shade-khv1: it seems that i've forgotten to cherry-pick this commit: d7fd75b65b64005b8bf1c7acdcb51825bc56dcc0 Feb 16 12:46:22 shade-khv1: go to the openembedded dir and type: git cherry-pickd7fd75b65b64005b8bf1c7acdcb51825bc56dcc0 Feb 16 12:46:29 shade-khv1: go to the openembedded dir and type: git cherry-pick d7fd75b65b64005b8bf1c7acdcb51825bc56dcc0 Feb 16 12:52:59 to the shr-testingwarning: too many files (created: 961 deleted: 697), skipping inexact rename detection Feb 16 12:53:07 Automatic cherry-pick failed. After resolving the conflicts, Feb 16 12:53:16 mark the corrected paths with 'git add ' or 'git rm ' Feb 16 12:53:30 and commit the result with: Feb 16 12:53:37 git commit -c d7fd75b65b64005b8bf1c7acdcb51825bc56dcc0 Feb 16 12:53:50 -------------- what is wrong? Feb 16 12:54:43 should i do someting like make clean and rebuild? Feb 16 12:56:33 do git status and look which file failed Feb 16 12:56:46 normally that should work just fine Feb 16 13:04:12 # On branch org.openembedded.dev Feb 16 13:04:12 # Unmerged paths: Feb 16 13:04:12 # (use "git reset HEAD ..." to unstage) Feb 16 13:04:12 # (use "git add/rm ..." as appropriate to mark resolution) Feb 16 13:04:12 # Feb 16 13:04:12 # both modified: recipes/openmoko-3rdparty/iliwi_git.bb Feb 16 13:04:40 Maybe its because i tried to solve error by myself Feb 16 13:05:29 i had changed /media/shr/shr-testing/tmp/work/armv4t-oe-linux-gnueabi/iliwi-0.0.1+gitr0+5be2b301033418fb9a33759047274b676034f096-r8/git/src/wifi.vala Feb 16 13:06:00 but then i clear all my changes, so it should be same Feb 16 13:06:35 how i can force git to ignore my changes? Feb 16 13:07:59 shade-khv1: look at recipes/openmoko-3rdparty/iliwi_git.bb and delete the not needed part in that file, either the one between <<<<<<< and ======== or between ======== and >>>>>> Feb 16 13:08:20 and then do git add recipes/openmoko-3rdparty/iliwi_git.bb Feb 16 13:08:24 i made shade@shade-A7N8X-X:/media/shr/openembedded$ git rm recipes/openmoko-3rdparty/iliwi_git.bb Feb 16 13:08:29 and git commit -c d7fd75b65b64005b8bf1c7acdcb51825bc56dcc0 Feb 16 13:08:49 looks like your changes was successfully applied then... Feb 16 13:09:01 shade-khv1: that makes everything worse ;) Feb 16 13:09:08 ^((((( Feb 16 13:09:23 shade-khv1: you should do make update again Feb 16 13:10:00 how? Feb 16 13:10:10 just make update Feb 16 13:10:34 in your OE dir Feb 16 13:11:23 or do git reset --hard Feb 16 13:11:34 in the openembedded dir Feb 16 13:11:40 have to go now Feb 16 13:11:56 you can ask in #openmoko-cdevel Feb 16 13:15:07 fatal: Your local changes would be overwritten by cherry-pick. Feb 16 13:15:07 Please, commit your changes or stash them to proceed. Feb 16 13:15:14 How to stash it& Feb 16 13:15:17 How to stash it? Feb 16 13:16:01 well, i better will delete entire directory and do make setip again Feb 16 14:07:35 shade-khv1: i will push an update for testing this evening at about 20 o'clock UTC, if you can wait until then you should wait :) Feb 16 14:11:57 i doing make setup (Initialized empty Git repository in /media/shr/openembedded/.git/). What i should do after 20? make update? Feb 16 14:42:05 shade-khv1: yes Feb 16 19:12:18 is it normal that kernel 2.6.34 from debian repo breaks FSO and X11? Feb 16 19:15:48 adiblol: from pkg-fso repo you mean? Feb 16 19:15:55 lindi-: yes Feb 16 19:16:00 adiblol: how does it break X11? Feb 16 19:16:01 but under debian Feb 16 19:16:11 X11 starts using almost 100% CPU Feb 16 19:16:23 adiblol: X11 probably ends up opening the accelerometer? Feb 16 19:16:30 adiblol: how's your xorg.conf? Feb 16 19:16:34 with glamo driver and with fbdev too. Feb 16 19:17:03 only Driver "fbdev" in Section "Device" Feb 16 19:17:17 adiblol: and nothing else? Feb 16 19:17:39 comments ;) Feb 16 19:17:42 and Identifier Feb 16 19:17:59 no other sections than "Device" Feb 16 19:18:33 adiblol: right. can you upload /var/log/Xorg.0.log? Feb 16 19:18:39 ok. Feb 16 19:20:25 lindi-: http://1tbps.org/static/Xorg.0.log Feb 16 19:22:51 adiblol: hmm, can you "sudo strace -p $(pidof Xorg) -o Xorg.strace" when Xorg is using 100% cpu? Feb 16 19:23:02 (just hit ctrl-c after it has logged someting) Feb 16 19:23:15 (II) config/udev: Adding input device lis302-1 (top) (/dev/input/event3) Feb 16 19:23:15 (II) No input driver/identifier specified (ignoring) Feb 16 19:23:23 suggests that it is correctly ignoring the accelerometer Feb 16 19:23:28 so my initial guess is wrong Feb 16 19:24:39 $(pidof X), not $(pidof Xorg) Feb 16 19:26:15 http://pastebin.com/raw.php?i=TKyfmbVu Feb 16 19:26:33 repeatidly Feb 16 19:26:45 repeatedly* Feb 16 19:26:55 adiblol: so it is always [11] there? Feb 16 19:27:14 adiblol: sudo ls -l /proc/$(pidof X)/fd/11? Feb 16 19:27:30 in select( ... ) call? Feb 16 19:28:10 it is always "(in [11])" Feb 16 19:28:14 yes Feb 16 19:28:24 that's the file descriptor number where it is getting new data Feb 16 19:28:32 /proc/1447/fd/11 -> /dev/input/mouse0 Feb 16 19:28:35 however, there really should be a read() call Feb 16 19:28:38 wtf?! Feb 16 19:28:46 mouse? :O Feb 16 19:28:56 mm yeah Feb 16 19:29:09 I guess I should test this on my system Feb 16 19:29:41 should I rmmod or something..? Feb 16 19:30:06 I just disable automatic configuration here Feb 16 19:30:13 but it's probably not the best approach Feb 16 19:30:40 adiblol: it's really not calling read() at all? Feb 16 19:31:38 strace -p $(pidof X) 2>&1 | grep read Feb 16 19:31:40 really. Feb 16 19:31:46 odd Feb 16 19:32:15 the kernel is just unstable ;) Feb 16 19:32:31 adiblol: dpkg-query -W 'xserver-*'? Feb 16 19:33:16 xserver-xorg-core 2:1.7.7-11 Feb 16 19:33:40 but what about the input drivers? Feb 16 19:34:10 http://pastebin.com/raw.php?i=Fxtj9Fna Feb 16 19:34:37 ok Feb 16 19:34:39 looks good Feb 16 19:35:14 yeah I think I know the bug Feb 16 19:35:23 (II) config/udev: Adding input device S3C24XX TouchScreen (/dev/input/event1) Feb 16 19:35:24 the same happened few months ago, also with Debian and unstable kernel. Feb 16 19:35:32 (II) config/udev: Adding input device S3C24XX TouchScreen (/dev/input/mouse0) Feb 16 19:35:46 it is essentially opening the touchscreen twice Feb 16 19:36:05 adiblol: is mouse0 a symlink to event1? Feb 16 19:36:26 nope. Feb 16 19:36:28 but... Feb 16 19:36:35 lrwxrwxrwx 1 root root 6 Feb 16 19:54 touchscreen0 -> event1 Feb 16 19:38:06 adiblol: mouse0 is probably still connected to the same hw Feb 16 19:38:13 just a different interface Feb 16 19:38:23 ok, how to disable it? Feb 16 19:38:47 adiblol: first try just removing mouse0? Feb 16 19:38:57 file? ok. Feb 16 19:38:59 to see if it workarounds this Feb 16 19:39:14 udev will recreate it on next boot Feb 16 19:41:40 seems to help. Feb 16 19:41:52 adiblol: ok Feb 16 19:41:54 ok, what about fso? Feb 16 19:42:04 adiblol: now the problem is that I don't know if the bug is in udev, linux or X Feb 16 19:42:29 I will workaround it in init.d Feb 16 19:42:38 adiblol: that won't help others :) Feb 16 19:43:08 on my laptop: Feb 16 19:43:09 $ ls -l /dev/input/|nc paste.dyndns.org 1234 Feb 16 19:43:10 http://paste.debian.net/107864 Feb 16 19:44:07 $ grep udev /var/log/Xorg.0.log|nc paste.dyndns.org 1234 Feb 16 19:44:07 http://paste.debian.net/107865/ Feb 16 19:44:18 so apparently having "TouchPad" twice is normal Feb 16 19:45:08 ah, that's because it fails to initialize it Feb 16 19:45:44 system screwed up. Feb 16 19:46:04 ...because network stopped working. Feb 16 19:46:16 hmm Feb 16 19:46:31 have to brutally reboot because openmoko-panel-plugin doesnt work Feb 16 19:47:25 I'd better reinstall the whole system. Feb 16 19:47:53 adiblol: I'm afraid I can't help you much with FSO. I'm avoiding it as much as I can :/ Feb 16 19:48:00 because it started being unstable after memory card problems. Feb 16 19:48:08 what is better than fso? Feb 16 19:49:05 adiblol: well I do use a tiny part of fso, the ogsmd for talking to GSM. but I don't use FSO to control backlight for example, I let Xorg do it. wiki.openmoko.org/wiki/user:lindi has some notes Feb 16 19:49:37 wtf? Feb 16 19:49:46 after reboot, fso works... Feb 16 19:52:59 network stopped working definitly... going to fully reinstall debian... Feb 16 19:54:51 seems that zhone breaks fso, then fso breaks openmoko-panel-plugin Feb 16 20:05:13 I could use older kernel, but I can't find sources of it. Feb 16 20:05:45 and I need sources to compile USB WLAN card modules. Feb 16 20:21:35 gamerunner 0.3 : http://lists.openmoko.org/pipermail/community/2011-February/064402.html Feb 16 20:22:27 radekp: sorry for the version I pointed you some days ago. That version still had the bug which breaks the FS on nand if you use it :(. Now the version released does not give that problem. Feb 16 20:24:22 zrafa: no problem, btw i tested it and my NAND still lives :) Feb 16 20:25:07 radekp: wow.. yes?.. well, great. BTW, the 0.3 released brings "the battle of wesnoth" :) Feb 16 20:25:32 radekp: and I removed xsoldier which I do not like much and there are several similar games better already. Feb 16 20:26:20 zrafa: nice, btw i like this distro very much Feb 16 20:27:24 zrafa: lots of games with very little effort, it's nice Feb 16 20:30:32 radekp: the idea of gamerunner is like a companion for qtmoko or shr :) .. and the second goal is to use the ancient effort of the community about games. The most of games ported by community were made for ancient kernels api and things like that. Feb 16 20:30:56 So most of them in gamerunner are the packages of games ported by community, which do not work on current distros. Feb 16 20:31:18 (like duke nukem, doom, etc, etc.. ). Feb 16 20:32:16 i saw also frontier on linux - that was nice game... Feb 16 20:37:36 yeah **** ENDING LOGGING AT Thu Feb 17 02:59:57 2011