Re: [Announce] CSSU Testing thread
 

No, I think that (any) daemon should have ability to write somewhere (fatal) errors. This is needed for future debugging and specially to check what caused device reboot... (enabling that *after* fatal error is useless). And syslog is the best option where to write it.

So totally disabling any output from pulseaudio to syslog is not good idea.

Re: [Announce] CSSU Testing thread
 

can anyone atleast guide as to what should be done. i am using cssu testing. and before the last 8.2 and 8.3 update the ringtone was working fine.

yes i get devel files when i get incompatible error is not for me but what is the solution if any there is as need this ringtone to be sorted. so could anyone tell how to go about it?

Re: [Announce] CSSU Testing thread
 

This should get you started:

http://talk.maemo.org/showpost.php?p...postcount=1359

Re: [Announce] CSSU Testing thread
 

so downgrading the PA packages is the way to go? well ok ill downgrade and report back...

Re: [Announce] CSSU Testing thread
 

No... It was just giving idea how to do it.

You can enable the CSSU-devel repo and then upgrade the necessary packages... It will be a bit easier than downgrading.

Re: [Announce] CSSU Testing thread
 

devel wud make things messy i jus dun want to mess about the phone and end up havin to flash it again. oh what a mess im in sigh..

Re: [Announce] CSSU Testing thread
 

A new update has hit the repo (21.2011.38-1Tmaemo9)

It contains quite some changes.
The massive changelog can be found on the wiki as usual:
http://wiki.maemo.org/Community_SSU/Changelog#Tmaemo9

Re: [Announce] CSSU Testing thread
 

so is that everything regarding ppoll etc now that glibc is updated?

Re: [Announce] CSSU Testing thread
 

You need a fixed kernel too (kernel-power >= 51r1 or kernel-cssu).

The next update will bring a kernel in CSSU(with the needed fix), hopefully

Re: [Announce] CSSU Testing thread
 

no worries, kp52 installed. will wait for a few days or until thumb version is released before updating.

Re: [Announce] CSSU Testing thread
 

I had advanced-power installed and ended up with two status area battery icons after upgrading. I've removed advanced-power now and back to the familiar old Maemo battery applet that I've not seen in a long time - was it to be expected that advanced-power would have this issue?

Re: [Announce] CSSU Testing thread
 

I like the "new" battery applet. Also the N900 alarm clock still works while the phone is powered off, nice. (I did set alarms on all my phones so that at least one wold wake me up in the morning just in case... N900 and Jolla worked, N9 woke up, but did not sound the alarm).

I really appreciate the work done for CSSU. Thanks to you all.

Re: [Announce] CSSU Testing thread
 

For everyone experiencing a broken fmtx/fmtransmitter please look here

Re: [Announce] CSSU Testing thread
 

I've changed the ringtone , and it seems the nokia one is playing also ,
maybe it's a bug , but I like it

Re: [Announce] CSSU Testing thread
 

Also as in "both plays at once", or as in "only nokia ringtone plays", or as in "sometimes it's my ringtone, sometimes Nokia's one"?

Re: [Announce] CSSU Testing thread
 

both at the same time

Re: [Announce] CSSU Testing thread
 

Is it safe to say that the pulse fixes from devel were pushed into testing with T9? I'm still on T7.2 and didn't upgrade to T8.x due to this problem (I don't keep track with devel if it was pushed). All I see in the changelog is

Re: [Announce] CSSU Testing thread
 

Thanks for the update!

Upgraded through the status area applet & HAM.
After the reboot decided to check if all packages were updated by running apt-get update and apt-get upgrade in terminal. To my surprise there were serveral packages to upgrade - it seemed that pulseaudio and qt4 packages were not up-to-date. So I upgraded these also and everything seems to be OK.
So - if you have ringtone problems - maybe it is good idea to check if all packages from the latest update got installed...

Re: [Announce] CSSU Testing thread
 

A new release (21.2011.38-1Tmaemo9.1) is in the repo.

This reverts fmtxd to the previous state, hence "fixes" the various fmtx problems for now.
It also contains proper dependencies for the updated Qt libs.

Re: [Announce] CSSU Testing thread
 

I have not seen this bug for a long time. I updated from 21.2011.38-1Tmaemo8.3+thumb2 to 21.2011.38-1Tmaemo9+thumb1

Re: [Announce] CSSU Testing thread
 

Any clue how to reproduce that?

Re: [Announce] CSSU Testing thread
 

first: landscape mode and switcher menu. Then I rotate phone to portrait for about 1s (I have disabled rotation animation) and back to landscape just before hildon rotate.

Re: [Announce] CSSU Testing thread
 

I have a bug report or a feature request for the calculator (not sure how the stock one behaved).

I often find myself typing same expression multiple times because I keep forgetting that "Clear till roll" does not clear an unfinished expression (i.e. without "=") from memory. This can lead to strange looking results, and the uncertainty usually makes me use dc instead. :(

Here are some examples (C stands for "Clear till roll", B for Backspace):

input: 2 * 3 C B 4 =
result: 4 = 8

input: 2 * 3 C B 4 * 5 =
result: 4 * 5 = 40

input: 2 * 3 * C B 4 =
result: 4 = 24

input: 2 * 3 * C B 4 * 5 =
result: 4 * 5 = 120

What I am requesting is to make it obvious what has been typed into the calculator, for example by making the "Clear till roll" button clear the unfinished expression from memory (and probably making the input box clearable in one press of Backspace, for convenience) or not clear the unfinished expression from the till roll.

Re: [Announce] CSSU Testing thread
 

Well, I noticed strange behavior of the latest battery applet. It reports 5 mAh (of ~1250), but sometimes the battery icon is green (as if ~10% was left), sometimes, for a while, it gets partially red (as if <5% with advanced-power) Should it be like that?

Re: [Announce] CSSU Testing thread
 

Battery has been reading 0% 5/1215mAh for the last hour or so. Finally got low battery notification/audible beep but battery indicator is still green.

Re: [Announce] CSSU Testing thread
 

Just to clarify things - we must be using different versions then, as the one I use from beta-releases *never* show low-battery warnings, just a "charge your battery"&shutdown thing on flat.

So, it seems, that for some reason (lower version number?), latest CSSU battery applet version doesn't over-write ages-old ones released by Pali, alongside experimental BME replacement.

Or I'm just mixing things up - in this case, feel free to correct me.

/Estel

// Edit

Battery applet version:
status-area-applet-battery_1.0-3_armel
...here, as opposed to CSSU'ish:
status-area-applet-battery_1.0-8_armel.deb

I wonder what the changelog is ;)

Re: [Announce] CSSU Testing thread
 

OOC I just checked behaviour of stock calculator. And it calculates correctly. Clearing the roll (menu/clear roll) cleares the current calculation.

[ot]What I like on this little calc is that it calculates 'Punkt vor Strich' correctly. Something the Harmattan one again unlearned.[/ot]

Re: [Announce] CSSU Testing thread
 

I've tested latest battery applet from cssu-t (status-area-applet-battery_1.0-8) and it immediately reminded me, why I had version 1.0-3 on "hold", set to custom-compiled, modified fork.

cssu's battery applet reports *absurd* values as battery max capacity, and for worse, it does so on purpose. It require some explaining, so bear with me:

Probably most of you are aware of the 3th pin of the battery, dubbed "BMI pin". There is a resistor between it and ground pin, which in theory, should provide information about "design capacity" of the battery - i.e. capacity battery should have, when new. It is *not* any form of measurement - it's just "hardcoded" by placing dumb resistor there, of set resistance value. Every value from reserved range is interpreted as some capacity.

The thing is, that no one - except Nokia - cares about that, and every 3rd party battery manufacturer in existence put there a random resistor of ~100kOhm value. Nor should they care, as it's dumbest way of giving *any* info about battery capacity - it doesn't compensate for battery aging, changes with temperature (as resistance changes), and overall, is completely and utterly useless. Heck, even Nokia doesn't seem to care much, as for batches of they upgraded BL-5J design, the sometimes correctly state ~1400 mAh, and sometimes, use same resistor as from older, 1300 mAh.
---

Now, back to battery applet - for some completely crazy reasons, Pali insisted on taking *this* info for applet's info about battery's max capacity. It is *worst* place to get that info - you could, as good, cat a /dev/urandom. Data used should be from bq27x0 chipset, and only from there.

At the same time, current capacity *is* pulled form bq27x00 (in case of someone, like me, using kernel-power and bme replacement), so it ends up in humorous, but completely crap'ish results. for example, currently, battery meter show that I have
...because current capacity is real (I'm using dual-scud battery), and max-capacity is taken from *** that resistor "hardcoded" value.
:)
---

Long time ago, when I actively betatested Pali's BME replacement and userland bits (including battery applet), I tried to reason with Pali, to no avail. He is great coder, but stubborn as usual, and deaf to any arguments. IIRC, user kerio insisted on same fix without success, so settled down on changing one line in applet's source code, and compiling own version (which I was using up to date).
---

Summing it up - as battery applet arrived in CSSU, and it's not governed by Pali alone, please people - fix it, as it's shaming to exist in current state.

Cheers,
/Estel

// Edit

Sorry for a little emotional nature of this post (but the meaning, while absolutely true, is also humorous, so I hope everyone read it as intended), but I just got instantly reminded of all those nn hours of trying to reason with Pali on IRC. While highly anegdotical experience, it's also kinda-traumatic. You know, this kind of contributing/beta testing stuff, that can give you flashbacks 30 years later ;)

Re: [Announce] CSSU Testing thread
 

Good to see people working on cssu. i have only one question: a lot of updates for testing (and thumb) but no updates for stable. when all the new features and fixes that are considered working properly in cssu testing will be added to cssu stable? as cssu stable users cannot install testing without flashing afaik. thanks

Re: [Announce] CSSU Testing thread
 

They can.
10 chars.

Re: [Announce] CSSU Testing thread
 

many people told me is not safe nor suggested, can be issues with repos, and you will need to flash suddenly...do you know a safe way?

Re: [Announce] CSSU Testing thread
 

I can't imagine a way this could go wrong.

Re: [Announce] CSSU Testing thread
 

What could be the reason why my phone isn't picking up the latest update? I'm currently on CSSU Testing T7.3 and I'm not being prompted to update to T9 when I update my repos through HAM. I'm able to install/uninstall applications just fine, I'm just not being prompted to update.

Re: [Announce] CSSU Testing thread
 

And as I guess, one cannot specify the source (bq27x00, bmi, or static override via config file - it would be a workaround)?

I expierienced this silly 1214/1170 mAh too.

Re: [Announce] CSSU Testing thread
 

With stock bme, new applet seems to use last_full, not design capacity. I have a 10 cycles.old BL-5J, design capacity 1415, bq27200 calibrated capacity of 1515, and bme last_full of 1215.

We all knew the mAh values reported by bme are more or less made up. The applet seems to report different percentage values than bme. bme will happily report a percentage that arithmetically doesnt add up with reporting.current/last_full or /design... For compatibility with old applet, using the percentage value reported by bme would probably make more sense.

Re: [Announce] CSSU Testing thread
 

Could it be possible (in the future) to enable a battery low warning, as in stock, with 5% in the new applet?

Re: [Announce] CSSU Testing thread
 

Sadly, no. I proposed it too something about half year ago, but... Eh.

I religiously agree :) BUT, we should also consider BME replacement users (AIUI, BME replacement as basic thing for CSSU is a long-term goal - frankly, even now it's more stable than some parts of CSSU), so making it configurable - with defaults as you proposed - would be best thing.

I don't care if config would be obscure gconf entry, or some file in the end of filesystem's universe, as long as I'm not forced to use certain values, just because applet detected something. A compromise defaults are OK, but lets make it configurable too and problem solved - we need less hardcoded things, not more.

Easier things said than done - although it's one-liner in code, convincing Pali is another thing. Even fact, that 100% of his bme-repl beta testers switched to kerio's "fork", wasn't enough to suggest that he may be wrong on this one. Even leaving any reasoning attempts aside ;)

/Estel

Re: [Announce] CSSU Testing thread
 

@Estel: there is already (for a long time) gconf key for specifing source of design capacity... By default it is from bq27200 and if battery is not calibrated it fallback to rx51_battery... If there is bug in that gconf key or somewhere else, you can report it. But I think that your problem has been already resolved by introducing gconf key for specifing source.

@merlin1991: Do you know, why are libqt4-meegographicssystem and libqt4-meegographicssystemhelper packages required in CSSU metapackage?

Re: [Announce] CSSU Testing thread
 

They shouldn't be pointed by the metapackage, as only some special applications may need it...

Re: [Announce] CSSU Testing thread
 

Ugh. If that is the case, then take my apologies, and I'll gladly stuff myself with my last post and eat it, alongside my left shoe.

BUT, I definitely have calibrated battery *and* bq27x00_battery module present&working, still, my "design capacity" is, by default, some rx51_battery nonsense.

I would love to report a bug, but before I'll do that, I want to test it myself in all possible ways - i.e., if that bug manifest itself if I edit said gconf key and revert it, etc. So, "stupid question" mode ON - where I can find documentation about such thing (aka, where the heck said gconf key is, and other things)?

Cheers,
/Estel