| 04:38.16 | jonwil | I just cloned osso-systemui-modechange :) |
| 05:19.08 | Sicelo | :) |
| 06:36.16 | *** join/#maemo-ssu Sicelo009N (~sicelo@unaffiliated/sicelo) |
| 06:50.20 | freemangordon | jonwil: why is that? https://github.com/community-ssu/osso-systemui-alarm/commit/ec77165f915698c96aede6796d8cdb1d4fb42531 |
| 06:57.02 | freemangordon | jonwil: those GtkWidget->GtkWindow are simply wrong, please revert those commits and use GTK_WINDOW(obj) cast when needed |
| 06:57.37 | freemangordon | s/are simply/changes are simply/ |
| 06:58.55 | freemangordon | see https://github.com/community-ssu/osso-systemui-alarm/commit/ec77165f915698c96aede6796d8cdb1d4fb42531#diff-845e439430941a41c60246e333118df9R950 |
| 07:00.00 | freemangordon | gtk_dialog_new() returns GtkWidget*, if you want to use that object as anything else, you should cast it with gtk macroses like GTK_WINDOW(), GTK_DIALOG() etc |
| 07:00.16 | jonwil | ok, will undo the change |
| 07:00.51 | freemangordon | c-style cast is not a good idea, as GTK_XXX does a runtime checks if the object can really be converted to the required type |
| 07:00.56 | *** join/#maemo-ssu Sicelo009N (~sicelo@unaffiliated/sicelo) |
| 07:01.08 | freemangordon | jonwil: just explaining why :) |
| 07:01.21 | jonwil | ok |
| 07:03.44 | jonwil | ok, I fixed it |
| 07:04.49 | freemangordon | jonwil: when you are sure everything works as it should, you may add "-DG_DISABLE_CAST_CHECKS" to CFLAGS, then runtime checks are not performed and GTK_XXX turns into a c-style check. see https://github.com/community-ssu/rtcom-accounts-plugin-gtalk/blob/master/configure.ac#L50 and bellow on a sane way this to be done :) |
| 07:04.59 | freemangordon | good |
| 07:05.21 | freemangordon | jonwil: btw, why did you do this change? |
| 07:06.17 | jonwil | I found clear evidence that those 4 systemui functions actually do take a GtkWindow and not a GtkWidget. More specifically, I found code that called those functions passing in GTK_WINDOW(blah) |
| 07:06.24 | jonwil | which wouldn't be appropriate if it was a GtkWidget going in |
| 07:07.31 | freemangordon | jonwil: hmm, a simle "git revert" should've been better, as commit description "more fixes" doesn't tell us much :), sorry to be picky, but in a month from now, we will have no idea what and why it was done :) |
| 07:08.16 | freemangordon | jonwil: then function should be declared as f(GtkWindow *) and all the callers should cast to GtkWindow |
| 07:08.37 | jonwil | all 4 functions are declared as f(GtkWindow) now |
| 07:08.51 | freemangordon | great |
| 07:09.02 | jonwil | the only mistake I made was not doing the right thing in osso-systemui-alarm |
| 07:09.59 | jonwil | I got confused because osso-systemui-alarm seems to be compiled with -DG_DISABLE_CAST_CHECKS |
| 07:10.13 | jonwil | and didn't realize I needed some macros in there |
| 07:10.34 | freemangordon | which we should use for all of the packages, but this is another story |
| 07:11.17 | freemangordon | jonwil: oh, and please, change debian/changelog files and put your name here, not mine or Pali's :p |
| 07:11.24 | freemangordon | *there |
| 07:11.24 | jonwil | oh sorry |
| 07:11.36 | jonwil | I used dch command to update changelog and didnt even notice the names |
| 07:11.45 | freemangordon | what is dch? |
| 07:12.09 | freemangordon | I always edit changelog files by hand |
| 07:13.52 | freemangordon | finds gtk type macros overly confusing sometimes :) |
| 07:14.12 | jonwil | anyhow, osso-systemui-alarm is using the right things now |
| 07:14.52 | freemangordon | jonwil: on a side note, how it is the correc way (in english, for plural): macroses or macros? |
| 07:14.52 | jonwil | modechange, tklock and powerkeymenu are fine as they didn't use G_DISABLE_CAST_CHECKS and hence I didn't get confused with either of those |
| 07:14.59 | jonwil | macros |
| 07:15.06 | freemangordon | ok, thanks |
| 07:15.52 | freemangordon | oh, yeah, it is macro for single, weird, as in Bulgarian we say "macros" for single. however |
| 07:16.37 | freemangordon | jonwil: this define swithes *runtime* checks off, not compile time, iirc |
| 07:16.58 | freemangordon | or there are warning in compile time as well? |
| 07:17.02 | freemangordon | *warnings |
| 07:17.27 | jonwil | there are compile time warnings if you pass the wrong pointer (e.g. a GtkWidget when it wants a GtkWindow) |
| 07:17.35 | freemangordon | oh, good |
| 07:18.42 | freemangordon | jonwil: actually what this "modechange" plugin does? |
| 07:19.17 | jonwil | If you are in airplane mode and you do an action that goes out of airplane mode (e.g. trying to activate a data connection) it displays a box saying "are you sure you want to leave airplane mode" |
| 07:19.32 | jonwil | Which doesn't happen if you press the "exit airplane mode" button on the powerkeymenu |
| 07:19.41 | freemangordon | I see |
| 07:20.04 | jonwil | easiest way to see is to press powerkey, press "offline mode" then press status bar then press "internet connection" button |
| 07:20.32 | freemangordon | got it |
| 07:22.29 | freemangordon | jonwil: BTW, could you share you hildon-whatever-nsv-something IDA db, to see if I can RE it further |
| 07:24.02 | jonwil | https://drive.google.com/file/d/0B9idqO9KygGsM0FoUW1GU0RNbm8/view?usp=sharing |
| 07:24.26 | jonwil | does anyone know what "act dead" state is? |
| 07:25.10 | freemangordon | sure |
| 07:25.13 | freemangordon | :D |
| 07:25.18 | jonwil | what is it? |
| 07:25.29 | freemangordon | jonwil: when you turn you device off and connect a charger |
| 07:25.42 | freemangordon | it turns on end enters "act dead" state |
| 07:25.58 | freemangordon | or when an alarm is triggered while it is turned off |
| 07:27.39 | jonwil | why it needs a systemui plugin (especially one that has UI) I dont understand |
| 07:28.12 | freemangordon | who needs it? systemui? |
| 07:28.28 | jonwil | yes there is a systemui plugin for actdead |
| 07:29.17 | freemangordon | well, take alarmui for example - it has a dialog asking you whether you want to "turn on the device" |
| 07:29.59 | freemangordon | dunno what actdead systemui does, but I guess we can find that easy |
| 07:31.35 | freemangordon | jonwil: keep in mind that ACT_DEAD mode has almost everything up and running, including X, dbus, etc. only hildon-desktop is not started afaik |
| 07:32.00 | jonwil | Is there a difference between act_dead mode and the "battery is too low to run normal system" mode? |
| 07:32.25 | jonwil | the one you get when your battery dies and your phone switches off then you plug it into a charger and it goes into a charging mode |
| 07:32.35 | freemangordon | yes, those are different |
| 07:32.55 | freemangordon | you enter ACT_DEAD when there is enough battery to boot maemo |
| 07:33.25 | freemangordon | but for some reason (like alarm triggered while off) you don;t want to enter USER mode |
| 07:34.14 | jonwil | does ACT_DEAD mode turn on radios or does it act like airplane mode? |
| 07:34.36 | freemangordon | when your phone dies because of a flat battery and you connect a charger, it is NOLO that does the so-called precharging, until there is enough charge to boot maemo and enter ACT_DEAD |
| 07:34.46 | freemangordon | afaik radis are off |
| 07:34.50 | freemangordon | *radios |
| 07:35.05 | freemangordon | so yes, it is like airplane mode in that regard |
| 07:35.19 | jonwil | radios being off makes sense otherwise an alarm could cause your phone to switch on at a point where cellular radios are banned for some reason (e.g. on an airplane) |
| 07:35.30 | freemangordon | yeah |
| 07:36.01 | freemangordon | that is why you're presented with a dialog asking you if you want to turn the device on |
| 07:36.41 | freemangordon | acually, if you select "no", the device is not turned off again, iirc :) |
| 07:40.30 | jonwil | anyhow, my next potential targets are the remaining osso-systemui pieces (main daemon, actdead, devlock, emergency, splashscreen) and also possibly osso-applet-devicelock, libdevlock and libcodelockui |
| 07:40.46 | jonwil | device lock UI would be useful since IIRC someone said it has problems in CSSU in portrait mode |
| 07:41.11 | freemangordon | isn't devlock == tklock? |
| 07:41.25 | freemangordon | or this is the one to enter the code? |
| 07:41.40 | jonwil | yeah devlock is the code entry |
| 07:41.43 | jonwil | for security code |
| 07:41.54 | jonwil | there is libdevlock which handles storing the code in CAL |
| 07:42.01 | jonwil | there is libcodelockui that displays the UI for it |
| 07:42.14 | jonwil | plus the systemui stuff for displaying the unlock dialogs |
| 07:42.21 | jonwil | and the control panel for setting the lock code |
| 07:43.07 | freemangordon | ok |
| 07:43.28 | jonwil | the same UI widget is used for pin code lock if your SIM is protected by a PIN I believe (connui-conndlgs-cellular does that bit) |
| 07:49.03 | jonwil | Not so sure the main systemui daemon is really worth reverse engineering actually |
| 07:50.05 | freemangordon | why not, it was a small binary iirc |
| 07:50.36 | freemangordon | what the?!? |
| 07:50.51 | freemangordon | jonwil: could you look at system_initialize in ...-nsv |
| 07:51.08 | freemangordon | I think there is a memleak |
| 07:51.33 | freemangordon | oh, no |
| 07:51.36 | freemangordon | my bad |
| 07:52.03 | jonwil | yeah systemui is a small binary but that doesn't mean its easy to RE |
| 07:52.11 | jonwil | I think the device lock stuff is a nice target to do next |
| 07:52.24 | jonwil | since there is a use for that (portrait mode device lock fixes) |
| 07:52.43 | freemangordon | yeah |
| 08:35.59 | *** part/#maemo-ssu mirda (~mirdaf@moravik.cust.sloane.cz) |
| 08:47.30 | bencoh | freemangordon: how do you display g_debug/g_warning? I guess I'm missing some magic envvar or args |
| 08:47.50 | bencoh | (with this version of gtk/glib ...) |
| 08:52.43 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 09:15.41 | jonwil | ok, so I figured out that the list of emergency numbers obtained by libcodelockui is only used to determine whether to display the "emergency call" button and that pressing that button doesn't pass what you typed into the unlock code box (911/112/whatever) to the phone subsystem, it passes a special magic string urn:service:sos which dials the real emergency number (oops). So my hack to make... |
| 09:15.43 | jonwil | ...it think "12345" was a valid emergency number (so I could test pressing the button and see it dial the invalid number 12345) went wrong. |
| 09:15.51 | jonwil | So from now on I wont touch that button at all |
| 09:35.15 | jonwil | Although I just found out that if you e.g. use dbus-send via SSH to dial a regular non-emergency phone #, it will properly dial even with the phone in locked state |
| 09:35.53 | jonwil | that said, if someone has ssh access to a locked phone and knows how to send a "dial number" command, they can also find a way to unlock the phone that way |
| 09:41.06 | bencoh | jonwil: ooooooh |
| 09:41.13 | bencoh | so that's how it works. |
| 09:47.49 | jonwil | note that rtcom-call-ui has special UI if the phone is locked and you are dialing a non-emergency number to indicate its locked and give you an option to activate the unlock screen |
| 09:52.53 | jonwil | So glad we have a reverse engineered MCE to play with, so many of the cool things I am fiddling with are tied into MCE |
| 11:38.32 | *** join/#maemo-ssu futpib (~futpib@176.104.194.78) |
| 13:12.28 | *** join/#maemo-ssu sparetire_ (~sparetire@unaffiliated/sparetire) |
| 13:15.03 | *** join/#maemo-ssu Sicelo009N (~sicelo@unaffiliated/sicelo) |
| 17:13.55 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 17:45.20 | freemangordon | bencoh: nothing special, besides syslog |
| 17:45.36 | freemangordon | keep in mind you have to reboot the device after installing syslog |
| 17:46.13 | bencoh | hmmm ... then I wonder why I dont see g_warning/g_debug messages in a custom gtk program (running from cli) |
| 17:46.19 | bencoh | oh ... how comes? |
| 17:46.44 | freemangordon | bencoh: you should use g_print, if you want those messages in the console |
| 17:47.24 | freemangordon | bencoh: device needs a reboot after installing syslog for the first time, bon't as me why :) |
| 17:47.29 | freemangordon | *don't |
| 17:48.29 | bencoh | but ... they're debug messages ... they shouldn't be displayed unless someone really wants it (?) |
| 17:48.59 | freemangordon | bencoh: usually you won;t see g_debug messages |
| 17:49.09 | freemangordon | thus you'd better use g_warning :) |
| 17:49.19 | bencoh | I dont see g_warning either |
| 17:49.25 | bencoh | that's what I dont understand |
| 17:49.31 | freemangordon | did you reboot? |
| 17:49.31 | bencoh | I guess I missed something :) |
| 17:49.37 | bencoh | launching from cli |
| 17:49.49 | freemangordon | no matter, did you reboot? |
| 17:49.54 | bencoh | what? |
| 17:50.03 | freemangordon | did you restart the device? |
| 17:50.10 | freemangordon | after installing syslog |
| 17:50.10 | bencoh | errr ... do you mean every single g_* message goes to syslog? |
| 17:50.17 | bencoh | and there is no way to override that? |
| 17:50.23 | freemangordon | there is a way |
| 17:50.51 | freemangordon | but yes, every g_... message goes to syslog, besides g_print() |
| 17:51.06 | bencoh | okay ... thx for the info :) |
| 17:51.37 | bencoh | I guess I really need syslog then |
| 17:51.52 | bencoh | (not just for this mafw debugging stuff) |
| 17:52.51 | bencoh | oh and ... not related to this, but what prevents us from shipping libgcc-4.7 in cssu (not just thumb)? |
| 17:52.56 | bencoh | is there some compat issue? |
| 17:55.28 | freemangordon | nothing afaik |
| 17:55.37 | freemangordon | we just need time and will |
| 17:57.16 | bencoh | okay |
| 17:57.28 | bencoh | do we have a non-thumb libgcc-4.7? |
| 17:57.44 | freemangordon | we have only non-thumg libgccc |
| 17:58.00 | freemangordon | hmm, typo day |
| 17:58.10 | bencoh | :) |
| 17:58.27 | bencoh | so we could just copy the package to -testing ? |
| 18:05.52 | kerio | can we have a thumb libgcc-4.7 |
| 18:07.34 | freemangordon | kerio: don't think so |
| 18:07.47 | freemangordon | or rather - don;t know how to do it |
| 18:12.37 | kerio | also can we have a thumb xorg compiled with 4.7 |
| 18:13.30 | freemangordon | why not? |
| 18:13.37 | freemangordon | I just need to find some spare time |
| 18:13.49 | freemangordon | and that's not easy :) |
| 18:16.06 | bencoh | setting up 4.7.2-thumb toolchain here :) |
| 18:17.18 | freemangordon | bencoh: you'd better find someone that can build toolchain, having 4.9 would be good IMO |
| 18:17.58 | bencoh | what do you mean by "can build toolchain"? |
| 18:18.06 | kerio | clang |
| 18:18.09 | kerio | clang is cool |
| 18:18.14 | kerio | fuck gnu |
| 18:18.37 | bencoh | kerio: errr ...not today(tm) :p |
| 18:19.30 | bencoh | freemangordon: "building" a toolchain isn't a real issue for me, but "packaging" it to make it work with sb is something else |
| 18:20.16 | bencoh | (oh, and we'd still need to apply err657417 patch to gcc) |
| 18:20.49 | bencoh | unless this has been worked around in 4.9? |
| 18:23.19 | freemangordon | вÑ
Ð°Ñ Ð¸Ñ err657417? |
| 18:23.23 | freemangordon | sorry |
| 18:23.28 | freemangordon | what is err657417? |
| 18:23.46 | freemangordon | bencoh: ^^^ |
| 18:26.50 | bencoh | http://wiki.maemo.org/Community_SSU/Thumb#ARM_errata_657417 |
| 18:27.55 | freemangordon | bencoh: the errata workaround is in ld |
| 18:28.31 | freemangordon | and is there since 2.20 iirc |
| 18:29.47 | bencoh | hmm |
| 18:30.00 | bencoh | then why do we need a different toolchain? |
| 18:30.38 | freemangordon | because 4.9 has more ARM optimizations than in 4.7. also, auto-vectoriser actually works afaik |
| 18:30.51 | bencoh | I mean 4.7 vs 4.2 |
| 18:31.14 | freemangordon | because 4.2 has a couple of thumb-related bugs |
| 18:31.19 | bencoh | oh okay |
| 18:31.29 | bencoh | hm and looks like it shipped ld 2.18 |
| 18:31.36 | freemangordon | that one too |
| 18:32.04 | bencoh | anyway ... what would we need to build a 4.9 toolchain> |
| 18:32.05 | bencoh | ? |
| 18:32.33 | freemangordon | no idea, it was tricky |
| 18:33.05 | freemangordon | I tried once to build 4.7.2 as debs, but there was some problem when installed in SB |
| 18:33.08 | merlin1991 | crosstools-ng and some debian packaging for the easy route ;) |
| 18:33.31 | freemangordon | merlin1991: SB has that packaging already (or some HOWTO, can't remember) |
| 18:33.48 | freemangordon | but setting all the build dirs, root, etc is tricky |
| 18:34.13 | freemangordon | also, -ng don;t do it iirc, you need to do it by hand |
| 18:34.22 | freemangordon | don;t do it correctly I mean |
| 18:34.53 | freemangordon | also, one should statically link host computer glibc etc, otherwise it won't run in SB |
| 18:35.04 | freemangordon | etc, etc,... |
| 18:35.30 | merlin1991 | hm I got crosstols-ng built arm toolchain running in sb2 but then again sb2 works quite differnt to sb |
| 18:36.07 | merlin1991 | never tried to load a different toolchain into our trusty scratchbox |
| 18:37.27 | kerio | i thought it was karmic, not trusty |
| 18:37.30 | kerio | huehue |
| 18:37.38 | bencoh | krkr :) |
| 18:40.31 | Sicelo | fun times |
| 18:40.33 | Sicelo | Oct 25 20:38:41 fremantle kernel: [ 2438.567230] memory_sync_page: no page for 4395b000 |
| 18:40.37 | Sicelo | Oct 25 20:38:41 fremantle kernel: [ 2438.567260] proc_memory_sync: InValid address parameters 4395a800 e80 |
| 18:43.04 | kerio | i wonder what would be a decent way to modernize maemo |
| 18:43.18 | merlin1991 | upgrade alll the libs? |
| 18:43.31 | kerio | what do you do with the statically-compiled, closed stuff? |
| 18:43.37 | kerio | i guess you keep the old libs around |
| 18:44.06 | bencoh | if they're statically-compiled you dont need the libs ;) |
| 18:44.12 | kerio | er yea |
| 18:44.16 | bencoh | but I guess you meant "linked against old libs" |
| 18:44.18 | kerio | yep |
| 18:44.28 | kerio | i doubt there's much that's statically compiled |
| 18:44.38 | kerio | given that space was (and is) quite a premium |
| 18:44.39 | bencoh | you check ABI compat and symbol dependencies |
| 18:45.53 | merlin1991 | kerio: did I mention, re all the bits? |
| 18:46.52 | kerio | let's just move to freebsd |
| 18:47.00 | kerio | i bet the nokia stuff runs fine in the linux compat layer |
| 18:47.18 | bencoh | meh :D |
| 18:57.51 | drathir | sad that maemo isnt based at at alar, but on the debian... |
| 18:58.03 | drathir | alarm* |
| 20:04.19 | *** join/#maemo-ssu jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 20:12.07 | jonwil | hi |
| 20:21.11 | *** join/#maemo-ssu Sicelo009N (~sicelo@unaffiliated/sicelo) |
| 21:08.24 | Pali | hi! |
| 21:15.12 | jonwil | Time to clone osso-systemui-devlock next I think, that and libcodelockui |
| 21:15.41 | jonwil | Then someone can add portrait device lock support to CSSU |
| 21:16.07 | jonwil | osso-applet-devicelock is on the todo as well |
| 21:16.31 | jonwil | Probably wont let you do portrait support for the other code lock stuff (i.e. sim pin codes) but who uses those anyway... |
| 22:17.51 | freemangordon | hi! |
| 22:36.05 | jonwil | freemangordon: any luck with the debian packaging for connui-internet? |
| 22:52.05 | freemangordon | jonwil: I don't need luck, but time :) |
| 22:52.12 | jonwil | ok :) |
| 22:52.16 | freemangordon | as soon as I have some, I'll do it |