| 00:41.20 | *** join/#maemo-ssu KrayonWork (~krayon@pdpc/supporter/28for7/krayon) |
| 00:45.44 | DocScrutinizer05 | SpacedOut: echo "DROP TRIGGER call_duration_inbound; DROP TRIGGER call_duration_outbound;DROP TRIGGER call_duration_voip_in; DROP TRIGGER call_duration_voip_out;" | sqlite3 -batch /home/user/.rtcom-eventlogger/el-v1.db |
| 00:46.02 | DocScrutinizer05 | will re-establish the buggy behaviour, if you really need it |
| 00:47.20 | DocScrutinizer05 | SpacedOut: I understand your concerns, but please understand that there's no per se right for continuity of bugs |
| 00:47.28 | SpacedOut | The tigger is a hack, I just don't need it since what I have does a much better job. |
| 00:48.28 | DocScrutinizer05 | well, if you got a better fix, then share it and we'll happily consider to use it |
| 00:48.37 | SpacedOut | If the rtcom-eventlogger-async is intended to be a run all the time daemon perhaps it can run the code I have. |
| 00:48.56 | DocScrutinizer05 | the trigger is no hack but a sub-optimal but working proper implementation |
| 00:50.10 | DocScrutinizer05 | of course it would be better if the eventlogger itself would populate the call duration column |
| 00:50.12 | SpacedOut | The package is minutemonitor already available for install. It has a small daemon that listens to dbus to do a better job of matching up the call start/end and which entry to update. |
| 00:51.10 | DocScrutinizer05 | aaah I see. An issue about concurrent calls. I wasn't even sure N900 can do that at all, until now |
| 00:52.02 | DocScrutinizer05 | having a dbus monitoring daemon sounds pretty much like another hack to me |
| 00:52.45 | DocScrutinizer05 | it should be rtcom-eventlogger itself doing the update of call duration col |
| 00:54.07 | SpacedOut | Agreed, it should be written by the same mechanism that writes the log in the first place, but the trigger blindly adds the elapsed time to the last phone entry, which is clearly the the wrong thing to do if the just ended call wasn't the last entry. |
| 00:54.43 | DocScrutinizer05 | yep, which only can happen on concurrent calls |
| 00:55.38 | DocScrutinizer05 | I think it's even mentioned in thread about original trigger "hack" |
| 00:58.21 | DocScrutinizer05 | worst thing that can happen as I see it now is that inbound minutes get booked on an outbound call. IIRC I already discussed that with author of that patch back when |
| 00:58.32 | SpacedOut | If I had those triggers, would sqlite3 show them with the `.table` command? |
| 00:59.06 | DocScrutinizer05 | we might want to further investigate it there's room for improvements regarding that special situation |
| 00:59.46 | DocScrutinizer05 | umm, it will show them with the correct command. I'm not expert enough to tell if .table is the right one |
| 01:01.37 | DocScrutinizer05 | why do you anticipate complications/collisions when both your improved dbus-monitoring thingie as well as the database triggers are installed and active? Wouldn't your stuff overrider the triggers anyway? |
| 01:02.44 | SpacedOut | No, it will only update the value if the current value is 0. |
| 01:02.54 | DocScrutinizer05 | aaah |
| 01:03.19 | DocScrutinizer05 | I fail to see the rationale behind that |
| 01:04.26 | SpacedOut | If it somehow gets the wrong row it won't overwrite what's already there since the N900 software doesn't put anything other than a 0 there. |
| 01:07.32 | DocScrutinizer05 | "somehow" isn't a goot term in an explanation of way of operation |
| 01:07.38 | DocScrutinizer05 | good* |
| 01:09.07 | DocScrutinizer05 | either it's deterministic, then we can find a way for co-existence. Or it's 'somehow' working 'sometimes', then it's hard to see how we could consider it as an alternative or problem |
| 01:12.03 | SpacedOut | It's been a while since I wrote that software to remember the details. I wrote it defensively, if things aren't as it expected it didn't mess with them. |
| 01:13.36 | DocScrutinizer05 | well, I can tell you what to expect |
| 01:14.36 | DocScrutinizer05 | either get rid of it, as suggested above, or get a 2s delay, then write the value unconditionally since you're sure it's better than what trigger does |
| 01:16.28 | DocScrutinizer05 | meanwhile we may ponder if the additional benefit of corretly handling concurrent calls is worth running another dbus-scripting monitor |
| 01:16.47 | DocScrutinizer05 | or we rather opt for fixing eventlogger |
| 01:20.25 | SpacedOut | Is there source available? Isn't it being told what to do from something else anyway? |
| 01:22.51 | DocScrutinizer05 | ATM I'm thinking about options to improve triggers to handle concurrent calls correctly |
| 01:24.39 | DocScrutinizer05 | alas it's pretty hard to test since I think I can't do concurrent calls here, with my contract |
| 01:26.53 | SpacedOut | I'm seeing if I had any notes on what else was wrong with the tigger method, but I'm not finding anything. I should compare the elapsed time to what I'm getting. |
| 01:27.29 | SpacedOut | VoIP gives the same results. |
| 01:35.56 | merlin1991 | freemangordon: ping |
| 01:39.04 | merlin1991 | this works async aswell, so I tried to compile microb-engine in my scratchbox again, this time I made a complete new sb target, added the cssu repos install the build dependencies and tried to build it, but it still failed |
| 01:41.51 | SpacedOut | DocScrutinizer05: The answer to my earlier question is a trigger is added to a table and printing that table's schema `.schema call_duration` prints any triggers there as well. I don't have the call duration triggers loaded and removing them works for me, I just need to know to remove them. |
| 01:43.20 | merlin1991 | freemangordon: here's the last few lines of output I get from the buildprocess: http://paste.debian.net/187324/ |
| 02:02.36 | DocScrutinizer05 | SpacedOut: keep an eye on changelogs (which I hope we'll publsih *prior* to rolling out actual update in the future [ merlin1991: hint hint]). Independently from changelog I'll try to keep in mind to leave you a note when we include triggers to CSSU |
| 02:04.18 | DocScrutinizer05 | SpacedOut: not only triggers but also when we update/fix rtcom-eventlogger |
| 02:05.03 | DocScrutinizer05 | SpacedOut: are we talking about S or T ? |
| 02:05.05 | SpacedOut | That would be great. Isn't rtcom-evenlogger closed source? |
| 02:05.15 | DocScrutinizer05 | I don't know |
| 02:06.02 | SpacedOut | I thought it was just logging in response to being requested, which would mean it probably doesn't have the information, short of listening on dbus signals like I'm doing. |
| 02:06.23 | SpacedOut | What's S or T? |
| 02:06.31 | DocScrutinizer05 | Stable or Testing |
| 02:06.56 | DocScrutinizer05 | what's your cssu flavour? |
| 02:08.00 | SpacedOut | deb http://repository.maemo.org/community-testing/ fremantle free non-free |
| 02:08.03 | DocScrutinizer05 | nevertheless I'd like to know if your CSSU is T or S |
| 02:08.11 | DocScrutinizer05 | T, ok |
| 02:10.14 | DocScrutinizer05 | note to self (and mohammad, merlin1991): send SpacedOut a mail when cssu-t will include triggers for call duration, like http://maemo.cloud-7.de/maemo5/patches_n_tools/eventsdb_calllog_triggers.sh, or implement a fix for same issue to rtcom-eventlogger |
| 02:11.45 | DocScrutinizer05 | reference: https://garage.maemo.org/pm/task.php?func=detailtask&project_task_id=1986&group_id=2300&group_project_id=3864 |
| 02:49.51 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 03:51.56 | *** join/#maemo-ssu M13 (~Miranda@83.149.35.143) |
| 05:37.46 | *** join/#maemo-ssu ekze (~nyan@bakaekze.ru) |
| 06:59.22 | *** join/#maemo-ssu luf (~luf@ip-89-103-166-30.net.upcbroadband.cz) |
| 07:28.07 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139) |
| 07:38.14 | *** join/#maemo-ssu luf (~luf@ip-89-103-166-30.net.upcbroadband.cz) |
| 08:31.09 | *** join/#maemo-ssu arcean (~arcean@aaes189.neoplus.adsl.tpnet.pl) |
| 08:34.02 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
| 10:27.12 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 11:30.04 | *** join/#maemo-ssu iDont (~dennis@145.93.232.89) |
| 12:01.00 | *** join/#maemo-ssu zeq (~s_j_newbu@2a01:348:1e3:1:e6ec:10ff:fe9a:d418) |
| 12:13.06 | freemangordon | merlin1991: "unable to dump 00114800" - where is that error coming from? |
| 12:13.23 | merlin1991 | that's the full output I get |
| 12:13.32 | merlin1991 | I guess I could check the makefile of the folder |
| 12:13.39 | freemangordon | the fuck :( |
| 12:14.05 | freemangordon | merlin1991: i can build it for you, it is ok here |
| 12:14.23 | freemangordon | might be related to host os, NFC |
| 12:14.38 | merlin1991 | well you'd have todo it with sb gcc |
| 12:14.41 | merlin1991 | maybe it's that? |
| 12:14.51 | merlin1991 | that you compiled with newer gcc? |
| 12:15.05 | freemangordon | merlin1991: don't think so |
| 12:15.11 | freemangordon | well, lemme try it |
| 12:27.54 | zeq | I've been really busy decorating last couple of weeks. I'll hopefully have some time soon to get back working on the important things... |
| 12:28.16 | *** join/#maemo-ssu Mephistopheles (~M13@170.133-224-87.telenet.ru) |
| 12:32.58 | freemangordon | zeq: well, take your time, men don't get married every day :P. |
| 12:33.30 | freemangordon | zeq: BTW my email was to make you aware that i've already did glibc thingie |
| 12:33.51 | freemangordon | to prevent you doing it once again |
| 12:36.50 | zeq | no worries, I just hate to say I'm going to do something then not having time to get it done! |
| 12:37.38 | freemangordon | well, sometimes it happens, after all we are all volunteers with a real life to deal with :) |
| 12:37.47 | zeq | yup |
| 12:38.08 | freemangordon | what worries me is merlin1991 unable to build microb-engine |
| 12:39.52 | zeq | against the patched libc? |
| 12:40.04 | zeq | or at all? |
| 12:40.25 | merlin1991 | zeq: at all |
| 12:40.36 | merlin1991 | freemangordon: maybe some build dependency is missing? |
| 12:41.27 | zeq | freemangordon: you can build it fine though? |
| 12:41.52 | merlin1991 | zeq: I made a completely clean now sb target and got this: http://paste.debian.net/187324/ |
| 12:41.58 | merlin1991 | s/now/new/ |
| 12:43.45 | kerio | would this be the same version as cssu-thumb, btw? |
| 12:46.03 | zeq | what gcc/build cflags |
| 12:46.49 | zeq | ? |
| 12:48.48 | zeq | binutils? |
| 12:50.10 | zeq | merlin1991: what version qemu devkit? |
| 12:51.10 | merlin1991 | binutils 2.18.50.20070820-4+0m5 qemudevkit 0.13.90-0rabbit1 |
| 12:52.22 | merlin1991 | zeq: ^^ |
| 12:53.28 | zeq | this is the sb standard gcc? |
| 12:54.18 | merlin1991 | yeah 4.2.1 |
| 12:58.55 | *** join/#maemo-ssu taziff (~Taziff@cyr108.internetdsl.tpnet.pl) |
| 12:58.57 | DocScrutinizer05 | hi folks |
| 13:00.21 | merlin1991 | moin |
| 13:05.11 | freemangordon | merlin1991: still clonning the repo :( |
| 13:05.32 | freemangordon | merlin1991: you can chech config.log for missing dependencies |
| 13:05.36 | freemangordon | check* |
| 13:09.40 | merlin1991 | hm I have a few of ac_nonexistent.h: No such file or directory |
| 13:09.48 | merlin1991 | int the various config.log files |
| 13:10.50 | jon_y | that is not an error in itself |
| 13:10.59 | jon_y | look lower |
| 13:13.31 | merlin1991 | tbh I never read those logfiles, dunno really what to look for |
| 13:13.47 | jon_y | configure --help is a good start |
| 13:14.10 | jon_y | it is possible some errors are entirely optional |
| 13:14.29 | jon_y | or just checking the host capability |
| 13:14.53 | jon_y | I wouldn't expect win32 WaveOut test to pass on N900 |
| 13:15.36 | merlin1991 | I think this is the right log for the compile fail in question: http://cdnm.at/~christian/maemo/cssu/microb-engine/config.log |
| 13:16.16 | jon_y | merlin1991: looks like it cut off half way |
| 13:17.01 | jon_y | last check was checking for setlocale |
| 13:17.36 | jon_y | and the config.log doesn't look like it was from autotools |
| 13:18.41 | jon_y | merlin1991: you omitting some stuff? |
| 13:25.35 | merlin1991 | nope |
| 13:25.42 | merlin1991 | that was a full scp of what I got locally |
| 13:25.51 | jon_y | it looks broken |
| 13:26.26 | jon_y | well, pipe and tail both stdout/stderr, looks more reliable |
| 13:27.13 | merlin1991 | how does one get stderr into stdout again? |
| 13:27.44 | jon_y | with bash: configure > log.txt 2>&1 |
| 13:28.12 | jon_y | or configure 2>&1 | tee log.txt |
| 13:31.13 | merlin1991 | complete build log: http://cdnm.at/~christian/maemo/cssu/microb-engine/build.log |
| 13:33.04 | jon_y | bug from ./../../dist/bin/run-mozilla.sh? |
| 13:33.41 | merlin1991 | what do you mean? |
| 13:33.58 | jon_y | ./../../dist/bin/run-mozilla.sh ./../../dist/bin/js imacro_asm.js /home/christian/n900/cssu-testing/microb-engine/microb-engine/js/src/imacros.jsasm > imacros.c.tmp |
| 13:34.01 | jon_y | unable to dump 00114800 |
| 13:34.07 | jon_y | it seems to be from ./../../dist/bin/run-mozilla.sh |
| 13:34.41 | jon_y | configure completed, so I don't think it's a dep problem |
| 13:36.23 | merlin1991 | run-mozilla.sh seems to be just a wrapper |
| 13:37.33 | jon_y | you'll need to go into it and find what is printing unable to dump 00114800 |
| 13:37.45 | jon_y | try sh -x ./../../dist/bin/run-mozilla.sh ..... |
| 13:37.46 | merlin1991 | it's actually /../../dist/bin/js |
| 13:37.59 | merlin1991 | that thingy throws unable to dump 0011480 |
| 13:39.34 | jon_y | you'll need to find out why it's doing that |
| 13:39.37 | merlin1991 | and it's a binary and the source to it does not contain any reference to "unable to dump" :/ |
| 13:39.59 | jon_y | what does sh -x say? |
| 13:40.09 | jon_y | maybe it calls another externel binary |
| 13:40.32 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@221.226.175.139) |
| 13:41.52 | DocScrutinizer05 | set trace on in shell ;-) |
| 13:42.56 | kerio | ~seen pali |
| 13:42.59 | infobot | pali <~pali@unaffiliated/pali> was last seen on IRC in channel #maemo, 6d 21h 21m 44s ago, saying: 'bye, I'm going offline for week or more...'. |
| 13:43.10 | merlin1991 | http://cdnm.at/~christian/maemo/cssu/microb-engine/run.log |
| 13:43.34 | merlin1991 | gotta run for now (exam) |
| 13:44.18 | jon_y | yup |
| 13:44.19 | jon_y | dist/bin/js |
| 13:44.20 | jon_y | unable to dump 00114800 |
| 13:44.26 | jon_y | its js, whatever it is |
| 13:46.44 | DocScrutinizer05 | js like javascript? |
| 13:47.16 | jon_y | maybe, I don't know what dist/bin/js is |
| 13:47.50 | jon_y | need to try strace dist/bin/js |
| 13:50.07 | freemangordon | build here started, lets see |
| 13:50.29 | DocScrutinizer05 | jon_y: google *might* help: https://bugzilla.mozilla.org/show_bug.cgi?id=462393 (loosely related) |
| 13:50.31 | povbot | Bug 462393: was not found. |
| 13:50.56 | DocScrutinizer05 | I suspect it's a js-version problem |
| 13:58.30 | DocScrutinizer05 | http://vocamus.net/dave/?p=1319 maybe also contains helpful background info |
| 13:58.42 | zeq | yes js is javascript |
| 13:58.45 | DocScrutinizer05 | seems it's actually a cmdline js "shell" |
| 13:58.52 | zeq | exactly so |
| 13:59.08 | zeq | it's a part of the mozilla build process |
| 13:59.47 | zeq | that's why I suspected the qemu ^ but the version seems ok |
| 14:01.08 | DocScrutinizer05 | I'd try something like "#~> dist/bin/js --version" and compare that between a working and a failing machine |
| 14:02.05 | DocScrutinizer05 | also check the js related packages installed on your host |
| 14:02.23 | DocScrutinizer05 | (whatever that might be) |
| 14:02.47 | DocScrutinizer05 | I gather jre1.6 etc is completely unrelated |
| 14:04.20 | freemangordon | WTF, it fails here too, but on a different place |
| 14:05.29 | freemangordon | "/home/maemo/workspace/tmp/microb/microb-engine/netwerk/protocol/http/src/nsHttpAuthCache.cpp:391: error: prototype for 'nsresult nsHttpAuthEntry::Set(const char*, const char*, const char*, const char*, const nsHttpAuthIdentity*, nsISupports*)' does not match any in class 'nsHttpAuthEntry'" |
| 14:10.22 | DocScrutinizer05 | hmm, dist/bin/js gets built before it's used it seems. |
| 14:11.01 | DocScrutinizer05 | and I can't see a --version command to query actual version of js-binary |
| 14:11.37 | DocScrutinizer05 | there's -j to "enable JIT trace" |
| 14:11.47 | DocScrutinizer05 | whatever that means |
| 14:12.13 | DocScrutinizer05 | meh, not my lawn |
| 14:20.14 | freemangordon | merlin1991: going to diif the sources in CSSU and maemo-extras, after all it seems romaza had no commited everything :( |
| 14:20.20 | freemangordon | *romaxa |
| 14:23.04 | zeq | freemangordon: is this he same microb-engine as you built for cssu-thumb? |
| 14:23.15 | zeq | or a new version? |
| 14:23.49 | freemangordon | zeq: yes, but I had the same error there, I was thinking it is because og gcc 4.7.2 and fixed it |
| 14:23.56 | freemangordon | https://gitorious.org/community-ssu/microb-engine/commit/88aac30c51f6150e866ab70c8e5a6b0cefdfd61d |
| 14:24.13 | freemangordon | now it turns out the base sources are not OK :( |
| 14:24.22 | zeq | a new version then? |
| 14:24.31 | zeq | yes I can click ;) |
| 14:25.19 | freemangordon | zeq: it is the same version for -thumb, if I parse your question correctly |
| 14:26.19 | zeq | so it builds with your toolchain ok? |
| 14:26.37 | freemangordon | zeq: I am trying to build master branch with gcc 4.2.1 |
| 14:26.53 | freemangordon | the above commit is in thumb-testing branch |
| 14:27.21 | freemangordon | doing diff between what is in maemo-extras and what is in CSSU repo gives 1.5M file :( |
| 14:30.24 | freemangordon | i'll clone again to have a clean tree |
| 14:30.45 | zeq | I have the feeling I'm missing too much context to say much meaningful |
| 14:32.37 | freemangordon | zeq: romaxa said he has uploaded the latest microb-engine sources on garage |
| 14:32.54 | freemangordon | we cloned that in CSSU and I applied the patches on top of it |
| 14:33.23 | freemangordon | now it turns out romaxa didn't put everything on garage and we have broken sources |
| 14:33.50 | freemangordon | that is why both me and merlin1991 fail to build microb-engine |
| 14:34.31 | freemangordon | I had to patch the same error i have now for thumb-testing branc, but I was thinking it is because of the new compiler |
| 14:35.02 | zeq | but it was just a bug in the sources |
| 14:37.26 | freemangordon | zeq: makes no sense, no way a buggy source can pass through autobuilder :D |
| 14:37.59 | freemangordon | which means that sources on garage (uploaded by romaxa) differ with those in maemo-extras |
| 14:38.03 | zeq | is completely confused |
| 14:38.17 | zeq | ok |
| 14:38.32 | freemangordon | zeq: there is microb-engine in maemo-extras, as tar.gz |
| 14:38.49 | freemangordon | there is also microb-engine on garage, as SVN repo |
| 14:38.56 | zeq | romaxa's is upstream? maemo-extras is pactched maemo release? |
| 14:38.57 | freemangordon | we were tol both are equal |
| 14:39.33 | freemangordon | they are supposed to be equal, i.e. patched maemo version |
| 14:40.15 | freemangordon | the one that comes with stock fremantle. we decided to use those from garage because of the commit history |
| 14:40.31 | freemangordon | fuuuck |
| 14:41.07 | zeq | that makes sense |
| 14:41.17 | freemangordon | i should've done that diff earlier instead of having trust in what romaxa had said |
| 14:41.33 | freemangordon | zeq: it is the same as with IPC lite client ;) |
| 14:41.37 | freemangordon | a total mess |
| 14:42.21 | zeq | I'm not a huge fan of mercurial mq from my experience trying to build IPCLite |
| 14:42.35 | freemangordon | did you succeed? |
| 14:42.43 | zeq | did you? |
| 14:42.47 | freemangordon | I tried to build it, no success |
| 14:42.58 | zeq | I will try again when I get time |
| 14:42.58 | freemangordon | patches do no ally |
| 14:43.05 | freemangordon | does not make sense |
| 14:43.15 | freemangordon | *apply |
| 14:43.15 | zeq | I manually fixed up all the patches, but shouldn't have to |
| 14:43.35 | freemangordon | is on his way home, bbl |
| 14:44.19 | zeq | obviously it works for romaxa |
| 14:44.29 | zeq | did you ask him how? |
| 14:44.52 | zeq | I've not really been online recently, as you've noticed |
| 14:48.30 | zeq | just attempted to ask romaxa about IPCLite, if I get a reply I'll mention microb too |
| 14:58.46 | *** join/#maemo-ssu LinuxCode (~LinuxCode@fedora/LinuxCode) |
| 15:06.06 | *** join/#maemo-ssu arcean (~arcean@aacz110.neoplus.adsl.tpnet.pl) |
| 15:11.42 | *** join/#maemo-ssu wmarone_ (~wmarone@c-67-174-151-253.hsd1.ca.comcast.net) |
| 15:13.07 | *** join/#maemo-ssu DocScrutinizer06 (~HaleBopp@openmoko/engineers/joerg) |
| 15:34.17 | *** join/#maemo-ssu zeq (~s_j_newbu@31.120.59.103) |
| 15:51.27 | kerio | will cssu eventually fix the optfs situation? |
| 15:53.46 | ShadowJK | with what, read-only onenand and overlayfs on emmc? |
| 15:54.25 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28F60.dip0.t-ipconnect.de) |
| 15:56.19 | kerio | omap_hsmmc compiled in the kernel, early mount of /home and bindmount for /usr to /home/usr |
| 15:56.20 | kerio | for instance |
| 15:56.39 | kerio | i mean, *really* early mount |
| 16:12.07 | freemangordon | merlin1991: ping |
| 16:17.59 | *** join/#maemo-ssu zeq (~s_j_newbu@2a01:348:1e3:1:e6ec:10ff:fe9a:d418) |
| 16:20.52 | *** join/#maemo-ssu wmarone_ (~wmarone@c-67-174-151-253.hsd1.ca.comcast.net) |
| 16:57.46 | freemangordon | merlin1991: ping |
| 17:07.37 | freemangordon | zeq: what will happen if we run pselect() glibc on top of non-pselect kernel? I know you alredy answered it, but I forgot what was the answer :S |
| 17:10.20 | zeq | freemangordon: pselect() will simply be unavailable. |
| 17:10.53 | freemangordon | aah, it won't boot :(. "Kernel version too low" |
| 17:10.59 | zeq | anything that tries to use it will fail with ENOSYS I think |
| 17:11.15 | zeq | even better! :) |
| 17:11.45 | freemangordon | zeq: I think glibc has a check for the minimum kernel version, I've encountered that when tried to chroot ubunto on my n900 |
| 17:11.48 | zeq | I'm not why you hit that though... |
| 17:11.53 | freemangordon | ^^^ |
| 17:11.59 | freemangordon | *ubuntu |
| 17:12.29 | freemangordon | well, just thinking whether it will fallback to emulation |
| 17:12.36 | zeq | it does, but it should be 2.6.28 according to the glibc change for pselect |
| 17:13.03 | freemangordon | so it will simply refuse to boot |
| 17:13.21 | freemangordon | hmm, 2.6.28? well, it will boot then |
| 17:13.59 | freemangordon | the point is - what will happen if soeone tries to boot with some old version of KP or with stock kernel? |
| 17:15.53 | zeq | as I said, it will run but pselect() will be unavailable |
| 17:16.13 | zeq | so anything that tries to use it will get upset |
| 17:16.33 | zeq | we could have a check during boot |
| 17:17.15 | freemangordon | merlin1991: I've rebased microb-engine on gitorious using the sources on maemo.org. You should be able to build it after git pull. It builds ok here |
| 17:17.26 | zeq | but I'm not sure what action it could suggest at that point other than flashing the right kernel |
| 17:17.37 | freemangordon | zeq: so no fallback? |
| 17:18.25 | zeq | freemangordon: that's right, there's either syscalls are used or emulation, it's either or. |
| 17:18.46 | kerio | freemangordon: well, kernel dependency is something that's been already tried out in cssu-thumb |
| 17:18.47 | DocScrutinizer51 | emulate pselect() like it's been done since ages |
| 17:19.05 | zeq | s/there's/there are/ |
| 17:19.07 | kerio | DocScrutinizer51: if the syscall fails? |
| 17:19.13 | kerio | ew, performance D: |
| 17:19.24 | zeq | that still makes so sense! :P |
| 17:19.43 | zeq | that's up to the app |
| 17:20.16 | freemangordon | zeq: sorry, I am not sure I understand correctly. So, if syscall fails with ENOSYS, glibc will fallback to emulated pselect() behaviour? |
| 17:20.56 | DocScrutinizer51 | glibc can fallback to emulation when kernel considered inappropriate |
| 17:21.10 | kerio | of course it can, but does it? |
| 17:21.17 | freemangordon | DocScrutinizer51: in theory or it is how it behaves now? |
| 17:21.20 | DocScrutinizer51 | should at least, could |
| 17:21.36 | DocScrutinizer51 | nfc how it behaves now |
| 17:21.50 | freemangordon | well, that is what i ask :) |
| 17:22.18 | freemangordon | how it behaves now (zeq's version of course) |
| 17:22.26 | DocScrutinizer51 | yes, seen that and concur with your rationale |
| 17:22.28 | *** join/#maemo-ssu taziff1 (~Taziff@cyr108.internetdsl.tpnet.pl) |
| 17:22.58 | DocScrutinizer51 | it should fallback to emu |
| 17:23.13 | freemangordon | :nod: |
| 17:23.39 | freemangordon | that will save us a lot of "dammit, my device don't boot after the last CSSU" |
| 17:23.52 | freemangordon | (after the last KP, you name it) |
| 17:24.10 | DocScrutinizer51 | if you 'patch' own function addr table there won't even be a performance penalty (just an irrelevant sidenote) |
| 17:24.53 | freemangordon | DocScrutinizer51: cannot parse that, sorry, would you elaborate |
| 17:25.13 | freemangordon | patch what? glibc or kernel? |
| 17:25.17 | DocScrutinizer51 | see how LD-PRELOAD works |
| 17:25.23 | kerio | freemangordon: you don't need to check every time pselect() is called |
| 17:25.37 | freemangordon | kerio: sure |
| 17:25.40 | kerio | so the performance loss ends up being a very small constant for each program that loads libc, or possibly even less |
| 17:26.19 | DocScrutinizer51 | you simply push a new symbol-addr tuple on glibc's symbol table |
| 17:26.20 | freemangordon | yep, I get that. the question is if it is implemented and if not, do zeq wants to implement it :P |
| 17:26.31 | freemangordon | kerio: ^^^ |
| 17:26.34 | DocScrutinizer51 | pointing to emu |
| 17:26.47 | kerio | zeq: do eeeeeeet |
| 17:27.08 | kerio | by the way, is the kernel patch in KP51r1 already? |
| 17:27.15 | freemangordon | kerio: no |
| 17:27.49 | DocScrutinizer51 | but actually nm, "overhead" for a conditional branch is negligible |
| 17:28.09 | zeq | seems rather hacky |
| 17:28.40 | kerio | DocScrutinizer51: maybe not, if you're running the thumb2 errata workaround |
| 17:28.42 | kerio | >:D |
| 17:29.11 | DocScrutinizer51 | but indeed glibc on init could check kernel for pselect and config itself accordingly |
| 17:29.37 | DocScrutinizer51 | kerio: eh? |
| 17:29.56 | kerio | the branch prediction cache is flushed on every context switch |
| 17:30.17 | DocScrutinizer51 | so what? telling me news? |
| 17:30.22 | zeq | DocScrutinizer06: you mean patch glibc on boot? |
| 17:30.28 | DocScrutinizer51 | yep |
| 17:30.40 | DocScrutinizer51 | not 'patch', just init |
| 17:31.07 | DocScrutinizer51 | each lib has its own init afaik |
| 17:31.37 | DocScrutinizer51 | in this init check if proper pselect or emu shall get 'exported' |
| 17:32.16 | freemangordon | zeq: a runtime check whether the current running kernel supports pselect() (and others) and initializing a function pointer should do the job too |
| 17:32.25 | zeq | I see |
| 17:32.33 | freemangordon | one time check |
| 17:32.56 | zeq | I guess that could work |
| 17:32.57 | freemangordon | that will save us a lot of headaches |
| 17:33.00 | DocScrutinizer51 | freemangordon: I thought I tried to say exactly that |
| 17:33.34 | freemangordon | DocScrutinizer51: sure, but you said it in such a complicated way, that we poor developers got lost :P |
| 17:33.41 | DocScrutinizer51 | the genuine function pointer is in symbol table |
| 17:33.48 | freemangordon | aah |
| 17:33.54 | freemangordon | didn't know that |
| 17:34.27 | *** join/#maemo-ssu zeq1 (~s_j_newbu@2a01:348:1e3::a20) |
| 17:34.44 | zeq1 | Sorry, battery went flat! |
| 17:34.58 | DocScrutinizer51 | see LD_PRELOAD |
| 17:35.15 | zeq1 | I wonder though, if it's so easy why glibc doesn't do that already? |
| 17:35.55 | kerio | because there's no reason to, really |
| 17:35.59 | freemangordon | well, usually you don't boot your linux with several kernel versions |
| 17:36.08 | kerio | usually you boot your linux with linux 3 |
| 17:36.12 | kerio | at least |
| 17:36.14 | DocScrutinizer51 | (sorry, Imm off home, so you have to follow 2 derefs to get from LD-PRELOAD to the function call to mess with symbol table) |
| 17:36.18 | freemangordon | at least I don;t |
| 17:37.15 | zeq1 | I guess it's mostly because in this case, other than ARM the version check is reliable and you simply can't boot with the wrong kernelk |
| 17:37.16 | zeq1 | s/kernelk/kernel/ |
| 17:37.28 | merlin1991 | freemangordon: I'll try to build it as soon as I've sorted my pc |
| 17:37.57 | freemangordon | merlin1991: ok |
| 17:37.59 | merlin1991 | (new ssd to replace the broken one, which leads to new windows installation, which in turn needs a new grub installation :D) |
| 17:38.16 | DocScrutinizer51 | afk shopping |
| 17:38.17 | freemangordon | zeq1: well, I guess n900 won;t boot too |
| 17:38.39 | zeq1 | I don't remember if it does boot or not |
| 17:38.47 | freemangordon | failing pselect in udev does not sounds like the system will boot :D |
| 17:38.48 | zeq1 | many things will be broken for sure |
| 17:39.12 | zeq1 | I think if I remember it does actually boot... but you can't run apt/dpkg ;) |
| 17:39.44 | zeq1 | I'm probably making that up though |
| 17:39.55 | zeq1 | I can't really remember what I tested with now |
| 17:40.09 | zeq1 | I remember.... |
| 17:40.34 | zeq1 | ... I installed the syscall glibc on a kernel that didn't support it, but didn't reboot |
| 17:40.56 | zeq1 | so I don't know if it would have rebooted, didn't dare try |
| 17:41.12 | zeq1 | used my backup libc to recover via LD_LIBRARY_PATH |
| 17:41.46 | freemangordon | zeq1: now you have a devel device you my want to try it :P |
| 17:42.02 | zeq1 | it's certainly much safer :) |
| 17:42.28 | zeq1 | my devel device works much better than my non-devel device btw |
| 17:42.38 | freemangordon | hehe |
| 17:42.53 | freemangordon | same here, but that is normal |
| 17:43.08 | freemangordon | you actually don;t have sim, IM accounts, etc, etc |
| 17:44.06 | zeq1 | not only that |
| 17:44.29 | zeq1 | but also there's a problem with the charging/booting with the other n900 |
| 17:45.23 | zeq1 | it usually cycles a couple of times to boot - rather weird. it works fine when it's up though. |
| 17:45.34 | zeq1 | I shouldn't turn it off ;) |
| 17:46.09 | zeq1 | but you're also right, about the performance being better, I put it down to not having so much crap running :) |
| 17:49.49 | zeq1 | My hildon-desktop build works really well on it. nice and smooth with no OC :) |
| 18:04.09 | *** join/#maemo-ssu arcean (~arcean@aacz110.neoplus.adsl.tpnet.pl) |
| 18:18.11 | amiconn | Hmm, bugs.maemo.org certificate expired a month ago... |
| 18:21.56 | DocScrutinizer06 | fact is, users *might* correctly install a non-pselect() kernel incl modules, which _should_ just work, but will (or may) spoil their day just due to glibc. A method *insdie* glibc to fall back to a possibly suboptimal but working emulation for pselect() would be a sane thing to implement |
| 18:22.21 | *** join/#maemo-ssu MrPingu (~Thunderbi@86.92.226.97) |
| 18:25.12 | freemangordon | DocScrutinizer06: :nod: |
| 18:33.53 | DocScrutinizer06 | freemangordon: (function pointer, symbol table) man dlsym; not exactly to the point but close enough to make your way from there |
| 18:35.06 | kerio | DocScrutinizer06: users aren't supposed to know that there's such a thing as a "kernel" |
| 18:35.34 | freemangordon | DocScrutinizer06: I think zeq1 is knowledgeable enough to be able to implement it :) |
| 18:37.17 | DocScrutinizer06 | I hope so. >> If a dynamic library exports a routine named _init(), then that code is executed after the load- ing, before dlopen() returns. |
| 18:40.07 | *** join/#maemo-ssu trumee (~parul@78-105-131-61.zone3.bethere.co.uk) |
| 18:41.08 | freemangordon | DocScrutinizer06: any idea if I can find n950 screen? |
| 18:41.51 | kerio | hahaha wat |
| 18:42.56 | freemangordon | an accident |
| 18:43.09 | kerio | buy vi__'s n950 |
| 18:43.28 | freemangordon | kerio: I need a screen, not a whole device |
| 18:43.40 | DocScrutinizer06 | in this code check for pselect() support in kernel, and if not provided, change addr-pointer to pselect() to the emulation |
| 18:43.42 | DocScrutinizer06 | I.E dlsym("pselect") returns a pointer to true pselect() or pselect-emu, depending on result of support check in _init |
| 18:45.01 | DocScrutinizer06 | never heard of any |
| 18:45.21 | DocScrutinizer06 | completely unclear what display is used |
| 18:45.32 | kerio | maybe it's the same as the n9 |
| 18:45.37 | DocScrutinizer06 | digitizer for sure is unavailable |
| 18:45.47 | freemangordon | kerio: it is bigger |
| 18:45.47 | DocScrutinizer06 | kerio: BS |
| 18:45.56 | kerio | i said maybe! |
| 18:46.00 | DocScrutinizer06 | N950 is LCD, N9 is amoled |
| 18:46.09 | kerio | ...wait, really? |
| 18:46.17 | kerio | who thought amoled was a good idea? :s |
| 18:46.18 | DocScrutinizer06 | yes, really |
| 18:46.32 | freemangordon | DocScrutinizer06: I took the picture of backover and controller |
| 18:46.51 | freemangordon | controller is atmel, but it seems like made for Nolia |
| 18:46.57 | freemangordon | *Nokia |
| 18:48.18 | freemangordon | MXT-NOK1 :D |
| 18:48.41 | DocScrutinizer06 | eeew |
| 18:50.15 | DocScrutinizer06 | well, google suggests it's not *completely* unknown, might be related/same mxt224 |
| 18:51.08 | *** join/#maemo-ssu trumee (~parul@78-105-131-61.zone3.bethere.co.uk) |
| 18:51.20 | DocScrutinizer06 | http://www.alibaba.com/product-gs/612807164/MXT_NOK1_MXT224.html |
| 18:52.30 | freemangordon | well, might be, but anyway controller is ok. |
| 18:52.48 | DocScrutinizer06 | http://www.aliexpress.com/store/product/1pcs-LOT-Original-Electronic-component-MXT224-CCU-MXT-NOK1/808897_568510723.html |
| 18:52.50 | freemangordon | the screen has 2 black stripes around half mm wide |
| 18:53.18 | DocScrutinizer06 | yeah, seems eventually everybody runs into that |
| 18:54.12 | freemangordon | otherwise it works ok, just looks ugly :D |
| 18:56.46 | freemangordon | maybe I should try and ask Nokia Bulgaria, who knows |
| 18:57.10 | freemangordon | though I can imagine their surprise when the see the device :D |
| 19:07.26 | kerio | hahaha |
| 19:12.14 | *** part/#maemo-ssu MrPingu (~Thunderbi@86.92.226.97) |
| 19:14.37 | *** join/#maemo-ssu trumee (~parul@78-105-131-61.zone3.bethere.co.uk) |
| 19:18.33 | DocScrutinizer06 | freemangordon: zeq1: if (! pselect-supported-in-kernel) {dlopen("glibc-helper-fakePselect.so")} |
| 19:18.48 | DocScrutinizer06 | ^^^ in glibc _init |
| 19:19.46 | DocScrutinizer06 | if nothing smarter comes to mind |
| 19:29.35 | zeq1 | pselect-supported-in-kernel() would have to call pselect() and see if it works |
| 19:30.24 | freemangordon | zeq1: hmm, it should call __syscall aiui |
| 19:30.32 | freemangordon | and check for enosys |
| 19:30.41 | zeq1 | yes, that's what I mean |
| 19:30.51 | freemangordon | yes, any problem with that? |
| 19:31.09 | zeq1 | (since pselect() is the glibc wrapper) |
| 19:31.54 | zeq1 | it's probably quite doable, especially since it's wrapped anyway |
| 19:33.01 | zeq1 | could modify the code on init to swap the syscall with a branch? |
| 19:33.40 | freemangordon | well, if it is function ptr there should be no problem |
| 19:34.34 | zeq1 | you're right, just include both functions and set the pointer accordingly after a test during init |
| 19:34.47 | freemangordon | exactly |
| 19:34.53 | DocScrutinizer05 | exactly |
| 19:36.56 | zeq1 | needs to go get something to eat |
| 19:49.37 | *** join/#maemo-ssu SpacedOut (david@SubSpace.fries.net) |
| 20:03.28 | DocScrutinizer05 | LOL |
| 20:03.32 | DocScrutinizer05 | jr@halebop:/> ld --help|wc -l |
| 20:03.33 | DocScrutinizer05 | 1357 |
| 20:06.03 | kerio | only 242 on maem |
| 20:06.05 | kerio | o |
| 20:06.19 | kerio | and only 1 on os x :D |
| 20:11.16 | kerio | ld64: For information on command line options please use 'man ld'. |
| 20:34.06 | *** join/#maemo-ssu arcean (~arcean@aacz110.neoplus.adsl.tpnet.pl) |
| 20:49.33 | *** join/#maemo-ssu BCMM (~ben@unaffiliated/bcmm) |
| 21:10.34 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 21:14.44 | freemangordon | merlin1991: ping |
| 21:23.31 | kerio | hmm, would you guys be ok with adding the extra commands in busybox-power to the cssu busybox package, if properly optified? |
| 21:23.31 | kerio | DocScrutinizer05: mostly you ;) |
| 21:24.36 | freemangordon | kerio: read how the Friday's conversation ended |
| 21:24.57 | DocScrutinizer05 | kerio: I fail to see how you'd possibly do that, unless you follow my suggestion to optify whole busybox-power and leave init busybox alone |
| 21:25.35 | freemangordon | DocScrutinizer05: iirc we agree that iDont will split bb in two |
| 21:25.43 | kerio | yay |
| 21:26.01 | DocScrutinizer05 | kerio: if you haven't noticed yet, you can't split busybox, it's one monolithic binary |
| 21:26.03 | freemangordon | leaving what is needed in rootfs and moving the resit in /opt |
| 21:26.13 | kerio | DocScrutinizer05: you can, however, put the symlinks somewhere else |
| 21:26.20 | DocScrutinizer05 | pffff |
| 21:26.31 | freemangordon | DocScrutinizer05: according to iDont it is possible |
| 21:27.03 | freemangordon | (should be) |
| 21:27.26 | kerio | /bin/busybox as close as the stock one as possible, maybe with patches and bugfixes after they are checked and tested, and with the same amount of features as the stock busybox |
| 21:27.47 | kerio | and then /opt/busybox/busybox which is basically the current busybox-power |
| 21:27.50 | freemangordon | kerio: lets not start that again, read the logs |
| 21:28.10 | freemangordon | it's been covered |
| 21:30.03 | DocScrutinizer05 | kerio: that's basically what I suggested, and that's basically two unrelated shell binaries |
| 21:31.20 | DocScrutinizer05 | and yes, I'm absolutely fine with that, since init and basic core system won't care about that stuff in /opt |
| 21:32.02 | kerio | the thing is, it could definetely be optional |
| 21:33.33 | DocScrutinizer05 | that's the main point |
| 21:33.54 | DocScrutinizer05 | another point being that even when you opt-in it won't eat space in rootfs |
| 21:34.27 | DocScrutinizer05 | and it will not introduce (per se) new risks into init process done by busybox basic |
| 21:35.37 | DocScrutinizer05 | and all the bb-p fans should be happy with that as well |
| 21:36.35 | DocScrutinizer05 | except those that still think it MUST NOT be optional, since busybox-power is so cool we have to forcefeed it to the rest of the world |
| 21:37.23 | DocScrutinizer05 | no matter what |
| 21:40.36 | DocScrutinizer05 | but it seems the most offensive and vocal fan of that "save the world" approach has actually taken an off-time from IRC |
| 21:41.03 | DocScrutinizer05 | I couldn't bother less to search tmo for his latest insults and lies |
| 21:44.10 | merlin1991 | freemangordon: pong |
| 21:45.15 | merlin1991 | My box is doing the 3rd reboot whilst installing 1 servicepack, windows sucks |
| 21:45.41 | merlin1991 | But I have grub in place by now :) |
| 21:48.07 | *** join/#maemo-ssu krayon (~fallen@pdpc/supporter/28for7/krayon) |
| 22:21.29 | DocScrutinizer05 | [2012-08-31 14:40:39] <merlin1991> kerio: it would use conflict: something which in ham only throws the use pc-suite to update error |
| 22:23.29 | DocScrutinizer05 | merlin1991: some "ideas": instead of "use PC suite mode" notification/error, we need a requester "conflicts! press yes for installing new and uninstalling the conflicting old. Press no to abort installation of new" |
| 22:26.34 | DocScrutinizer05 | merlin1991: another "idea": since cssu-extras is supposed to not kill old HAM, could we already get one or two optional packages (possibly void dummy test packages, or anything we wanna get anyway into extras like bb-p) and check it works like expected with 'old' HAM, I.E. doesn't show up (aiui) |
| 22:33.48 | merlin1991 | DocScrutinizer05: as long as a package isn't in a user/* section *old* ham just ignores it |
| 22:34.17 | merlin1991 | it's even better on harm, when you dl a deb that isn't in such a section the pkgmrg fails with a generic error :D |
| 22:34.59 | DocScrutinizer05 | err |
| 22:43.56 | DocScrutinizer05 | afk for late night beer |
| 23:38.59 | *** join/#maemo-ssu wmarone_ (~wmarone@c-67-174-151-253.hsd1.ca.comcast.net) |