**** BEGIN LOGGING AT Tue Feb 23 02:59:58 2010 Feb 23 04:43:58 ~bark Feb 23 04:43:59 * apt barks, like a rabid dog. Feb 23 05:01:25 ~balmer Feb 23 05:01:49 ~gates Feb 23 05:01:50 well, gates is the evil dweeb running Microsoft or a man wanting to send us all through the Gates of Hell Feb 23 05:34:06 ~ding Feb 23 05:34:07 dong Feb 23 05:39:57 apt, ignore DocScrutinizer Feb 23 05:39:58 * apt sticks her fingers in her ears. "La, la, la! I can't hear you, DocScrutinizer!" Feb 23 05:42:32 sounds like my silly girlfriend Feb 23 05:51:44 ~bing Feb 23 05:51:45 i heard bing is an Empirical stochastic bandwidth tester Feb 23 05:52:17 ~google bing Feb 23 05:53:19 mwester: got a few days off? Feb 23 07:32:57 JaMa, please bump e, there has been updates in illume2 (final version is there) Feb 23 07:45:45 TAsn: I already did about a week ago, and then reverted it in few mins, because wizard was strange Feb 23 07:46:04 TAsn: before that I was testing it with .e already created from before and it was ok Feb 23 07:46:20 TAsn: and then after another restart even wizard started to behave.. Feb 23 07:46:44 so maybe I reverted too soon :/ Feb 23 07:46:48 sometimes you have to del e Feb 23 07:47:16 JaMa, anyhow, new illume2 (final version feature-wise) is there Feb 23 07:47:16 I know, but problems started when I did Feb 23 07:47:21 oh Feb 23 07:47:25 which is bad Feb 23 07:47:25 thought the other way around Feb 23 07:47:28 yeah Feb 23 07:47:34 what rev did you try? Feb 23 07:49:11 TAsn: I'm not sure if that's doable in theme, but closing and app-switching button would be great to move from bottom panel to top and remove bottom panel Feb 23 07:49:34 TAsn: in that revision I tried there is still a "bug" when you have keyboard on, than you cannot see those 2 buttons Feb 23 07:49:39 I think it is possible in profile+theme Feb 23 07:49:56 so if you open terminal, then you have to hide keyboard to close it or switch to different app Feb 23 07:50:15 JaMa, devilhrons is the guy to ping if you have issues/questions :P Feb 23 07:50:35 46275 Feb 23 07:50:36 anyhow, I think that's doable in theme+profile Feb 23 07:50:44 how old is it? Feb 23 07:50:58 TAsn: I know, I talked with him, before first trying illume2 :) Feb 23 07:51:01 latest is 46383 Feb 23 07:51:19 more than a hundred commits later :P Feb 23 07:51:27 02/18/10 07:15 Feb 23 07:51:44 I'll bump to latest.. Feb 23 07:51:45 Does anyone know if you can currently run SHR (other other such distros) in qemu these days? Feb 23 07:51:57 krayon: afaik still no Feb 23 07:52:07 JaMa, ciao. :P Feb 23 07:52:11 and thanks. Feb 23 07:52:13 surf is up Feb 23 07:52:17 * TAsn is going surfing. Feb 23 07:52:22 Quite some time ago I was able to run the OpenMoko distro, pre-QT days. Feb 23 07:52:31 krayon: or yes if you build it for qemu, but not just download gta02 images and boot them in qemu Feb 23 07:53:24 JaMa: I see. Feb 23 07:54:31 I utilised the shr.bearstech.com/Makefile to retrieve files as per yhttp://wiki.shr-project.org/trac/wiki/Building%20SHR however there's no explicit mention of building for qemu on there. Feb 23 07:58:57 http://wiki.openmoko.org/wiki/Qemu Feb 23 07:59:41 JaMa: your home server seem to be not responding Feb 23 08:00:32 JaMa: Yes that's what I followed some time ago I believe, but I'm not sure if it'll work these days - I also was not sure how relevant it would be to SHR. Feb 23 08:00:33 krayon: seems a bit updated from last time I check.. so please check what I said there.. Feb 23 08:01:26 krayon: when I tried it about a year ago.. the description didn't work for me.. but you can build shr for generig qemu target in OE Feb 23 08:01:51 krayon: if you're not interested in playing with FR specific things like accels, wifi, gps... Feb 23 08:02:22 PaulFertser: hmm I'm writting from it and gallery also seems to be up Feb 23 08:02:44 JaMa: So you could run that on standard qemu from my distro repo? Feb 23 08:02:55 oh my. Relicensing is really a pain. Feb 23 08:02:59 oops, wrong win Feb 23 08:03:00 PaulFertser: but I don't see any hit in apache log from your ip Feb 23 08:03:03 Connecting to jama.homelinux.org|78.24.13.161|:80... Feb 23 08:03:24 JaMa: probably your IP is not what dns think? Feb 23 08:03:39 PaulFertser: no that's right ip Feb 23 08:04:00 strange :/\ Feb 23 08:04:15 JaMa: wget http://jama.homelinux.org fails for me from any host Feb 23 08:04:30 PaulFertser: works for me. Feb 23 08:04:55 PaulFertser: and ping and tracepath works ok? Feb 23 08:04:55 krayon: hm, worked for me too from other host now Feb 23 08:06:09 maybe it will be slow (openoffice build running), but should work ok Feb 23 08:07:44 JaMa: :-O from one host: http://paste.debian.net/61050/ , from my home PC: http://paste.debian.net/61051/ Feb 23 08:09:27 PaulFertser: ah that's because VHS is dead :) they shoud use DVD instead :) Feb 23 08:09:36 ah it's VSH not VHS Feb 23 08:10:54 krayon: btw, you know that using Qemu doesn't make much sense because you can build all the shr apps natively. And run them in a nested x-server if you want. Feb 23 08:13:04 PaulFertser: Oh really. That would probably be the better choice I guess :P Feb 23 08:13:39 PaulFertser: Last I looked at all this was before the Neo1973 was available, and I just purchased a freerunner and wanted to see what I have to look forward to. Feb 23 08:14:00 krayon: cool, i hope you'll enjoy this pos ;) Feb 23 08:14:50 PaulFertser: I'm assuming pos == Piece Of Superb-hardware? Feb 23 08:15:01 krayon: of course! Feb 23 08:15:17 :) Feb 23 08:15:18 :) Feb 23 08:15:27 krayon: in fact to look at screenshots you can go to scap.linuxtogo.org Feb 23 08:15:41 I would like to do some development in this space but it all seems rather complicated, a lot to learn about getting the build env up etc Feb 23 08:16:16 krayon: yes.. shr building is always fun Feb 23 08:16:23 krayon: you can go the Debian route Feb 23 08:16:37 krayon: and you have to write simple patch from time to time.. so it's also good intro for development :) Feb 23 08:16:37 pbuilder + qemubuilder when necessary Feb 23 08:18:22 As stated, I have retrieved the SHR Makefile but this bitbake thing doesn't seem to finish what it's doing :/ Feb 23 08:19:48 krayon: building a whole distro from scratch is a long process. Feb 23 08:19:55 krayon: OE is something very similar to gentoo. Feb 23 08:20:39 PaulFertser: Yes I figured as much, though it's been sitting at 80% for quite some time and doesn't appear to be using resources. Feb 23 08:20:57 krayon: parsing recipes? Feb 23 08:20:58 krayon: possibly it's trying to connect some host that is down atm Feb 23 08:20:59 Do you happen to know if SHR downloads anything during the "make image" process? Feb 23 08:21:21 Ah. I'm at work atm and behind some rather draconian "security" :P Feb 23 08:21:22 krayon: yes it downloads everything it needs to build it Feb 23 08:21:23 It's probably that. Feb 23 08:21:41 krayon: at least you need git:// working for some recipes Feb 23 08:21:51 JaMa: Oh I already downloaded the initial stuff Feb 23 08:22:28 Is it possible to cross compile SHR or (another distro for the freerunner) on a desktop to speed things up a bit? Feb 23 08:22:32 Or is that too problematic? Feb 23 08:22:41 I did a "make setup" that apparently retrieves FSO, SHR and bitbake Feb 23 08:22:43 riuh: OE always cross-compiles Feb 23 08:23:30 krayon: do "ps ax" and probably you'll see what it is waiting for. Feb 23 08:23:47 PaulFertser: how fast is building debian in qemu/neo? Feb 23 08:23:48 PaulFertser: ok thanks Feb 23 08:23:54 PaulFertser: Yeah it's a git thing :P Feb 23 08:24:20 PaulFertser: I'm building on neo only really simple testcases (ie for that qtxml bug), but it's so slow.. compared to desktop Feb 23 08:25:22 krayon: if you replace all AUTOREVs in conf/distro/include/shr-autorev.inc with valid latest revisions, then it should go OK without git:// working Feb 23 08:26:02 What is the state of SHR these days? I've been out of the loop for a (long) while... Feb 23 08:26:04 Boot up speed? Battery life? Core phone functionality? Feb 23 08:26:37 krayon: but then you still need to build only revisions already build on shr buildhost (which creates git snapshot tarballs for download) Feb 23 08:26:44 JaMa: do you have problems with builing librsvg-native? for me it can't find atk.h Feb 23 08:27:12 Heinervdm: seen that too, can you try to rebuild gtk+? Feb 23 08:27:25 JaMa: will try Feb 23 08:27:50 Heinervdm: I'm not sure it was the "fix" I used, but IIRC something overwittern gtk.h headers in staging and then it failed for me Feb 23 08:28:22 JaMa: building on device is slow :( Feb 23 08:28:35 JaMa: but one can buy a SheevaPlug for debian work Feb 23 08:30:46 JaMa: there's also distcc available, it provides considerable gains imho. Feb 23 08:31:18 Heinervdm: maybe I remember a bit more.. that rewritten gtk.h was including just atk/atk.h or atk.h, but new one is using right atk-1.0/atk.h or fixes gtk-config Feb 23 08:31:33 JaMa: Do I have that option though? I haven't built anything as yet. Feb 23 08:32:30 krayon: yes you can replace those revisions with latest revs available here http://build.shr-project.org/sources/ Feb 23 08:32:34 krayon: if you can ssh out to somewhere, you can use ssh -D option and tsocks to wrap the bitbake invocation. Feb 23 08:32:58 krayon: but it's a bit of work.. so if you can tunnel git:// from your network, it's faster solution Feb 23 08:45:28 hmm.. So if I can just change the MACHINE var to x86, I can build to run locally? Feb 23 08:49:24 krayon: no, take a look at SHR build instructions, there's mention of some file with "local" versions or something. Feb 23 08:50:36 PaulFertser: They have a local.conf but it's only for a few settings that I can see. Their auto.conf contains DISTRO, MACHINE, IMAGE_TARGET etc Feb 23 08:50:59 krayon: i think you need to enable additional local-builds.conf or something Feb 23 08:51:06 PaulFertser: It's MACHINE is set to "om-gta02" which I noticed a file in openembedded/conf/machine of hte same name. Feb 23 08:51:51 PaulFertser: Ah, yes I see that now. Feb 23 08:53:13 One other thing, If I am writing my own apps, just C based stuff, could I just cross compile locally and then be able to run the binary or do I need this whole environment to build anything that'll run on the hardware? Feb 23 08:53:57 krayon: depends on the dependencies ;) Feb 23 08:54:01 PaulFertser: JaMa: Thank you very much for your assistance btw, much appreciated. :) Feb 23 08:54:41 krayon: for some really simple C stuff you can also build on the device itself, at least that's what i do, it's ok. Feb 23 08:54:50 PaulFertser: But it can be done then? Feb 23 08:55:05 Yeah so hello world will probably work :P Feb 23 08:55:54 krayon: for any crosscompilation you basically need to have all libraries that your program depends on cross-compiled too. For native compilation you can have everything easily installed on device itself, and you can even use distcc to speed up the process enourmously. Feb 23 08:56:50 PaulFertser: you can also do native build + distcc'd cross-compilers Feb 23 08:57:05 PaulFertser: no need to install cross-compiled libraries in that case Feb 23 08:57:20 PaulFertser: I see. Feb 23 08:57:24 lindi-: exactly what i imply Feb 23 08:57:30 no? Feb 23 08:57:58 lindi-: well, "any cross-compilation" didn't include using a bare crosscompile on host. Feb 23 08:58:01 :) Feb 23 08:59:26 Do these distro's have a fairly complete set of c libraries? Feb 23 09:00:05 krayon: yes Feb 23 09:00:11 There would be something nice about being able to gcc on my phone :D Feb 23 09:05:17 If I want to code a simple graphical C app will GTK be my best option for SHR? Feb 23 09:05:45 Which toolkit(s) is/are used by the core SHR applications? Feb 23 09:08:04 riuh: efl/enlightenment Feb 23 09:08:11 and gtk is available too Feb 23 09:11:40 spaetz: thanks for the info Feb 23 09:15:10 np Feb 23 09:24:30 Sorry does anyone know off hand: Feb 23 09:24:31 Which EWL widget is used to get a toggle switch like `mic on' `toggle volume'? Feb 23 09:27:41 riuh: http://trac.enlightenment.org/e/wiki/Elementary Feb 23 09:28:41 heh libsyncml issue is also gcc bug :) Feb 23 09:29:21 hopefully even fso stuff will be more stable after fixing gcc and rebuilding all Feb 23 09:29:23 JaMa: gtk+ rebuild doesn't solve librsvg thing Feb 23 09:29:51 Heinervdm: do you have /usr/include/atk-1.0 in staging? Feb 23 09:30:02 JaMa: yes Feb 23 09:31:04 but i can do a rebuild from scratch... Feb 23 09:32:20 do you have the log? Feb 23 09:32:38 Heinervdm: thanks Feb 23 09:33:00 Heinervdm: or just grep where is wrong atk.h included Feb 23 09:35:30 JaMa: there is no -I for atk-1.0 dir Feb 23 09:39:49 I'll try to rebuild here, mmt Feb 23 09:41:18 JaMa: perhaps that is because i had newer atk installed Feb 23 09:41:25 Heinervdm: did you rebuild gtk+-native or just gtk+ ? Feb 23 09:41:33 just gtk+ Feb 23 09:41:47 ah sorry gtk+-native should do it Feb 23 09:41:53 ok Feb 23 09:42:10 Heinervdm: I have right -I in ./Makefile:GTK_CFLAGS Feb 23 09:43:52 Heinervdm: I was considering what did rewrite that in staging, do you have this recipes also installed in failing state? gdk-pixbuf-csource-native-2.12.11-r7.0.do_build glib-2.0-native-2.22.4-r1.do_build ? Feb 23 09:44:56 JaMa: only glib Feb 23 09:45:06 ok thanks I'll check it Feb 23 09:45:18 JaMa: ah no gdk too Feb 23 09:46:09 ok Feb 23 09:47:35 Heinervdm: gdk-pixbuf-csource-native_2.12.11.bb is the problem Feb 23 09:47:46 Heinervdm: just rebuilt that and librsvg-native is failing Feb 23 09:47:52 ok Feb 23 09:47:59 not sure what is pulling that Feb 23 09:48:20 Heinervdm: can you fill a bug in OE about that or should I? Feb 23 09:48:43 JaMa: will do it Feb 23 09:49:26 Heinervdm: ah librsvg-native itself is pulling that in Feb 23 09:49:30 hmm, forgot my password for OE bugzilla Feb 23 09:49:36 Heinervdm: as well as few other recipes :/ Feb 23 09:50:28 JaMa: can you file the bug? i can't remember my password :) Feb 23 09:50:39 Heinervdm: I guess that bumping that recipe to latest version would fix the issue too Feb 23 09:50:53 ok.. later :) Feb 23 10:00:52 JaMa: found my password, the problem was the username, it's an email adress not a username Feb 23 10:03:09 http://bugs.openembedded.org/show_bug.cgi?id=5405 Feb 23 10:03:27 ok :) Feb 23 10:06:03 Heinervdm: btw do you have any idea if gdk is now build as part of gtk+? Feb 23 10:06:47 Heinervdm: I don't know what's relation between gdk and gtk+ but current gtk+ recipe directory seems more difficult than I would expect :) Feb 23 10:07:02 JaMa: we have gtk+-native version 2.12.11 Feb 23 10:07:18 -native is quite old... Feb 23 10:09:01 Heinervdm: no :) Feb 23 10:09:05 PROVIDES = "gdk-pixbuf" in gtk+.inc Feb 23 10:09:08 Heinervdm: we have 2.18 sth Feb 23 10:09:18 Heinervdm: because of BBCLASSEXTENDS Feb 23 10:09:21 ah Feb 23 10:09:38 Heinervdm: as also specified in preferred-shr-versions IIRC Feb 23 10:10:19 JaMa: we have 2.18.3 in SHR Feb 23 10:10:30 but BBCLASSEXTENDS is only in 2.18.6 Feb 23 10:10:49 oh no Feb 23 10:10:53 Heinervdm: I guess that gdk-pixbuf-csource is some really stripped version when it's enough for you and you don't want to pull whole gtk+, but for us we already have whole gtk+ Feb 23 10:10:57 we have 2.18.6 Feb 23 10:11:10 PREFERRED_VERSION_gtk+ = "2.18.6" Feb 23 10:11:10 PREFERRED_VERSION_gtk+-native = "2.18.6" Feb 23 10:12:42 rm ${D}${bindir}/gdk-pixbuf-csource Feb 23 10:12:45 yes I remember also adding P_V for gtk+-native also to angstrom config because of this issue Feb 23 10:13:08 http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/gtk+/gdk-pixbuf-csource-native_2.12.7.bb Feb 23 10:13:53 this one is maybe fixing that debug output about failing pixbuf loaders I've seen somewhere, not really remmembering where Feb 23 10:14:20 that's an older version as we have Feb 23 10:16:25 lunch.. Feb 23 10:18:28 arrg, librsvg-native fails to compile Feb 23 10:19:51 spaetz: :D Feb 23 10:20:04 spaetz: read last 20 lines ;) Feb 23 10:20:24 rebuilding gtk+-native solves that Feb 23 10:31:22 ahh :) Feb 23 10:31:26 thanks a lot :) Feb 23 10:32:14 yw Feb 23 10:32:17 :) Feb 23 10:32:54 JaMa: do you know x86 assembly a bit? Can you explain this idiom: 18fb: e8 fc ff ff ff call 18fc ? Feb 23 10:34:26 PaulFertser: without context my "a bit" is not enough Feb 23 10:34:52 JaMa: should i add 18fc to $pc to understand what it will call? Feb 23 10:36:01 It doesn't look right Feb 23 10:39:12 PaulFertser: I don't understand "should i add 18fc to $pc to understand what it will call" that's what call instruction does for you, isn't it? Feb 23 10:39:57 JaMa: i'm trying to understand a disassembled binary and this instruction puzzles me, i can't understand where it's going to transfer the control. Feb 23 10:40:54 I would say to next line 18fc Feb 23 10:42:52 PaulFertser: can you pastebin surrounding lines? Feb 23 10:46:17 JaMa: sure Feb 23 10:47:27 JaMa: http://pastebin.com/xLK9C13E Feb 23 10:50:48 JaMa: also to my limited understanding this opcode should be translated like "call -4" Feb 23 10:54:29 lindi-: do you have any idea please? Feb 23 10:54:49 ah now I see, and you're right.. it's strange (wrt my very limited asm knowledge) Feb 23 10:57:34 PaulFertser: bit more context might help :) Feb 23 10:57:56 PaulFertser: also, tried singlestepping it? Feb 23 10:58:37 PaulFertser: calls like that are usually used to get contents of EIP register Feb 23 10:58:39 farhaven: nope, it's just a listing i'm puzzled by Feb 23 10:59:02 PaulFertser: hmm, perhaps those FF's get filled by dynamic linker? Feb 23 10:59:06 PaulFertser: if this ia a library? Feb 23 10:59:11 lindi-: the context is here: http://pastebin.com/xLK9C13E , i can provide more of course. But it puzzles me a lot. Yes, a library. Feb 23 10:59:18 PaulFertser: then it's quite clear Feb 23 10:59:31 Damn, didn't think about the linker. Feb 23 11:00:37 PaulFertser: so just look at GOT and PLT Feb 23 11:01:06 lindi-: big thanks for the hint Feb 23 11:01:47 PaulFertser: what are you trying to do? ;) Feb 23 11:03:12 lindi-: to evaluate how hard it is to solve this bug http://bugs.freedesktop.org/show_bug.cgi?id=17902 by disassembling a small X driver. Feb 23 11:04:50 PaulFertser: lots of comments, summary please? ;) Feb 23 11:05:08 PaulFertser: some proprietary driver supports that and you try to reverse-engineer? Feb 23 11:05:28 lindi-: intel didn't release the source for some not that widely used DVO-lvds converter Feb 23 11:05:49 lindi-: and i'm trying to understand how hard it is to get the necessary info from the binary. Feb 23 11:05:56 Since the datasheet is incomplete. Feb 23 11:13:30 PaulFertser: wouldn't it be easier to look at the IO instead? Feb 23 11:13:52 lindi-: who knows. I just want to understand what it takes to reverse a small binary. Feb 23 11:14:30 lindi-: and i still can't fully understand the "E8" opcode. And this particular example since it references the byte after IP, not some memory location with PLT. Feb 23 11:15:01 PaulFertser: did you tried -R with objdump? Feb 23 11:15:05 PaulFertser: afaik those FFs are just a filler that will get overwritten Feb 23 11:15:14 PaulFertser: their value does not matter Feb 23 11:16:11 ynezz: wow Feb 23 11:16:55 Big thanks guys, i learn something new from you every day! Feb 23 11:17:14 boomerang is an automatic x86 to C converter Feb 23 11:17:32 PaulFertser: how does that dump looks now? Feb 23 11:17:37 PaulFertser: i'd still recommend looking only at the IO traffic Feb 23 11:17:50 PaulFertser: much more clean-room Feb 23 11:20:30 why does e-wm depends on libpam? Feb 23 11:20:51 ynezz: now it looks great Feb 23 11:21:05 lindi-: i do not care about clean room. Feb 23 11:22:07 lindi-: even if i translated that stupid driver to C keeping all the logic i'd still think that'd be a fair use. Those fuckers should have released it in the first place. Feb 23 11:22:32 PaulFertser: but fair use does not exist in all countries that Xorg is used Feb 23 11:22:41 s/that/where/ Feb 23 11:23:17 lindi-: who cares, i doubt even if somebody does what i say intel would make a noise out of it. Feb 23 11:23:38 PaulFertser: but debian won't include the Xorg driver changes then :) Feb 23 11:23:52 lindi-: debian included a non-free "nv" driver Feb 23 11:23:58 So that's a nonsense talk Feb 23 11:24:23 PaulFertser: yes at a time it was not seen as an issue Feb 23 11:24:43 PaulFertser: but nowadays new packages might be looked more carefully Feb 23 11:24:49 lindi-: i can't understand how a non-free driver can be seen like a non-issue. Feb 23 11:25:11 PaulFertser: well there are even some comments :) Feb 23 11:25:25 lots of numbers of course too Feb 23 11:25:36 lindi-: btw, tracing IO is complicated because one needs the hardware in question, a specific old Xfree86 version etc etc. Feb 23 11:25:49 yep Feb 23 11:26:24 PaulFertser: and it is not a non-issue, it is marked as a release critical bug Feb 23 11:26:32 since 2006 Feb 23 11:26:46 lindi-: and yet they had releases instead of throwing it out? Feb 23 11:26:57 lindi-: they could have declared that "vesa" is enough. Feb 23 11:27:11 ynezz: this option is pure magic, i wished i understood how it works :) Feb 23 11:27:15 PaulFertser: yes debian has decided to make such compromises Feb 23 11:27:22 on a release-by-release basis Feb 23 11:27:58 lindi-: i guess if debian didn't, then this would make a great fuss and something would have changed. Because not everybody knows "nv" is non-free. Feb 23 11:28:13 PaulFertser: yep Feb 23 11:28:34 PaulFertser: they should have noticed this ages ago before including it Feb 23 11:28:41 I guess it would even harm reputation of some Xfree86 devs who's accepted the obfuscation and that'd be well-deserved. Feb 23 11:29:06 but now that it has been in the distro for ages it takes a while to remove it without causing surprises on upgrade Feb 23 11:33:11 hi all Feb 23 15:15:25 DocScrutinizer, it might take alittle longer that expected because the doc is not as good as the website claims, so i have to dig through the sources (i only need 2 or three functions and maybe a forth for exportig if desired) Feb 23 15:20:12 but the rendering quality is better than in firefox Feb 23 16:33:07 JaMa: are you sure that this will work? http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=5c3846f9bbf1dbb4a9ee1d916107747c2f9dc909 Feb 23 16:34:23 won't it be called on every start, if pointercal exists? Feb 23 16:39:09 Heinervdm: yes that's what I intended Feb 23 16:39:28 Heinervdm: if you have /etc/pointercal.xinput then that .sh will just use that Feb 23 16:39:49 so you create one and it will be used every time Feb 23 16:39:59 or not create one and this whole section will be ignore Feb 23 16:40:07 JaMa: ah ok, i tought that will just show that calibration screen Feb 23 16:40:20 and you should create one by calling /usr/bin/xinput_calibrator_once.sh with ssh connection working Feb 23 16:40:42 Heinervdm: no that's why I added this .sh wrapper around xinput_calibrator binary Feb 23 16:40:52 but for this we need a default password Feb 23 16:41:15 Heinervdm: empty password should be allowed already in openssh Feb 23 16:41:25 ok Feb 23 16:41:45 and partially not so important now, because you won't see calibration screen for first boot Feb 23 16:41:54 (that's whole point of removing it now) Feb 23 16:42:12 and after first boot you should have passwd from last step of wizard :) Feb 23 16:42:25 so you can check if it works and run that script Feb 23 16:43:13 the problem is, if the calibration is completly wrong then you have no chance to create a password Feb 23 16:43:28 and there were some users with this problem Feb 23 16:44:12 with static calibration from weiss? Feb 23 16:45:06 yes Feb 23 16:45:11 I think it was completely wrong only if xinput-calibrator somehow failed or was executed in wrong time (ie without previous kernel driver "precalibration") Feb 23 16:45:57 Heinervdm: I'll remove this if, as soon as Tias implements that confirmation dialog Feb 23 16:46:05 Ne, some users complained about it before you added xinput-calibration Feb 23 16:46:14 Heinervdm: btw, have you read todays shr-u thread? Feb 23 16:46:19 for those we added xinput-tslib Feb 23 16:46:36 ah I see Feb 23 16:46:45 mcnavi, or which? Feb 23 16:46:56 I didn't know about users with completely wrong calibration only slightly off Feb 23 16:47:06 [Shr-User] building shr-testing fails at building image Feb 23 16:47:14 sorry it's hidden in that thread Feb 23 16:47:18 i don't remember how, but there were at least 2 Feb 23 16:47:44 yes i've seen that Feb 23 16:47:47 but now they should be able to use empty password in openssh Feb 23 16:48:19 that's ok, the one i remember did it that way with kdrive Feb 23 16:49:02 I just refused to read complains about wrong calibration.. because of xinput-calibrator wrongly used (I agree it's difficult to use especially when you don't expect it to show up - that's why I sent heads-up e-mail when I did, but seems it's not enough) Feb 23 16:49:28 the calibration problem only occures with broken hardware, so that aren't that many people Feb 23 16:50:18 but xinput-calibration is usually broken when display goes off (because fsodeviced not ready or fsoraw not installed) Feb 23 16:50:43 and you have to tap the screen on random place and it's counted as first touch for calibration.. Feb 23 16:59:04 Heinervdm: you can close that bug you fixed with eglibc, it's building atm Feb 23 16:59:48 hmm, i think there was no ticket about that Feb 23 17:00:20 but for ldd there is one Feb 23 17:01:50 ah so maybe it was only on ML Feb 23 17:02:13 it was here on IRC Feb 23 17:02:21 or here.. but I remember someone complaining about that missing file.. Feb 23 17:02:30 yes :) Feb 23 17:03:03 so for that one: libpthread_nonshared.a will be in eglibc-dev soon Feb 23 17:03:39 oh, just silly but hear what happened to me: I was in desktop and I've pressed kb button to show kb. When I returned to the phone, shr-today screen was there.... and the kb is covering half of it, the toggle too, so I can't exit from shr-today Feb 23 17:03:59 pespin: what about AUX button? Feb 23 17:04:11 Heinervdm: yes should be Feb 23 17:04:13 JaMa, oh, great :D Feb 23 17:04:38 Heinervdm: and I'm expecting to bump distro_pr in near future :/ Feb 23 17:05:29 Heinervdm: -Os creates buggy code only with gcc-4.4.* so as soon as we have fix for that, I would like to rebuild whole images Feb 23 17:06:33 JaMa: gcc bug? cool, what's the bug report number? Feb 23 17:07:00 JaMa, did you bump efl? Feb 23 17:07:23 TAsn: yes Feb 23 17:07:30 does it work? Feb 23 17:07:34 (can I upgrade?) Feb 23 17:07:35 lindi-: still diffing that.. Feb 23 17:07:45 TAsn: seems working for me.. Feb 23 17:07:53 is it in feeds? Feb 23 17:07:56 TAsn: yes Feb 23 17:08:16 JaMa: not reported yet? Feb 23 17:08:28 lindi-: no.. not enough info to describe it.. Feb 23 17:08:40 * TAsn is issuing an: opkg update && opkg upgrade Feb 23 17:08:50 JaMa: i think you should report it as soon as possible even if you don't know which exact commit caused it Feb 23 17:09:33 lindi-: I'm not in bisecting gcc phase yet.. but that qtxml test case is much bigger than gcc guys would like I think.. Feb 23 17:10:03 mrmoku|away, thanks to you or the one who bumped emtooth rev65 ;) Feb 23 17:10:07 lindi-: so I have other case in libsyncml, which is a bit difficult to reproduce because it fails only on arm4+gcc44 combination Feb 23 17:10:25 and even armv5+gcc44+Os works (if I didn't overlook something Feb 23 17:10:45 lindi-: but whole test-unit series included there can pass Feb 23 17:10:59 lindi-: and when used from python bindings (with pisi) it segfaults (only for Os) Feb 23 17:11:16 JaMa: got some nice testcase? Feb 23 17:11:36 JaMa: as in "1) build foo 2) run bar"? Feb 23 17:11:44 lindi-: if you don't mind building qt4 .. (libqtxml*.so is enough) Feb 23 17:12:15 JaMa: upstream does not use -Os normally? Feb 23 17:12:17 lindi-: micola mfd sent me small testcase which does/doesn't work base on how libqtxml was built Feb 23 17:12:38 lindi-: in OE is default to use -O2 for glibc based and -Os for eglibc Feb 23 17:13:18 lindi-: but I didn't try to rebuild it with -Os on my amd64 Feb 23 17:13:50 but as that libsyncml breakage happen only on armv4, than it's maybe a bit arch dependent in qt too Feb 23 17:18:17 lupan: any hint for http://tinderbox.openembedded.net/packages/494770/ ? just updated recipe to use moved repo and it works ok on my host, and fails on shr buildhost Feb 23 17:19:39 lupan: nvm, ignore that.. it's probably because eglibc build is still running.. so I guess that's just valac is having hard time.. without headers.. Feb 23 17:20:29 vibrator is only connected to battery? Feb 23 17:20:33 can't vibrate without a bat? Feb 23 17:21:29 TAsn: checked the schematics? Feb 23 17:21:45 no, I just noticed it Feb 23 17:21:49 so it's probably true :P Feb 23 17:21:53 was just surprised. Feb 23 17:22:57 TAsn: if "VB" is battery then yes Feb 23 17:24:16 thakns :P Feb 23 17:26:25 JaMa: cookie :) http://patchwork.dev.bearstech.com/patch/673/ Feb 23 17:26:35 TAsn, is illume2 still unusably slow on moko? Feb 23 17:26:36 Heinervdm: building locally already :) Feb 23 17:26:56 no idea Feb 23 17:27:03 should be way faster and memory efficient Feb 23 17:27:06 just upgrading and checking Feb 23 17:27:08 JaMa: http://tinderbox.openembedded.net/public/logs/task/5118308.txt says there is no elm.vapi, is elementary build there properly? Feb 23 17:27:17 * JaMa never seen illume2 slower than illume1 Feb 23 17:27:19 JaMa, no e upgrade available Feb 23 17:27:23 TAsn, i checked yesterday: unusalbe (at least with defautl theme) Feb 23 17:27:38 JesusMcCloud, default theme should suck, but you were using a very old illume2 version Feb 23 17:27:39 and I'm using illume2 for about 2 months maybe Feb 23 17:27:43 they did a rewrite since that. Feb 23 17:27:50 JaMa, no e upgrade available :| Feb 23 17:27:54 aha Feb 23 17:28:03 TAsn: than you have to w8 a bit sorry.. Feb 23 17:28:10