0.3 in testing is OK, but 0.3 in devel has currently some dependency issues. 0.2 in extras i OK, but lacks some features
So for anyone having problems it might be worth checking what repository you are trying to install from, and if you want v0.3 make sure you are using extras-testing by disabling extras-devel
Edit: An update on this. Someone tested using another application of mine (webtexter) that was having the same problem. When they had devel enabled, they could not install. Then they disabled devel and enabled testing it installed correctly.
Install yes, updating is the issue. If you download from one repository you can't update from another repository's version (well, at least as far as I can tell).
I did what you said, but in order to get the testing Extended Call Log, I had to uninstall the one I had. I get the feeling the version number for the one in devel was higher (ie, newer) than the one I got from testing.
Install yes, updating is the issue. If you download from one repository you can't update from another repository's version (well, at least as far as I can tell).
I did what you said, but in order to get the testing Extended Call Log, I had to uninstall the one I had. I get the feeling the version number for the one in devel was higher (ie, newer) than the one I got from testing.
I don't know how the application manager deals with applications from different repos. I thought it was based on version number and they should both have the same version (see http://maemo.org/packages/view/extcalllog/)
I'm considering pushing it to extras in the hope that it will solve the issue for most people but I'm slightly worried that it would cause issues for people in extras. Does anyone know if promoting it might cause any issues now?
Hmm.. Seems I was wrong, matrim. Even though my current Extended Call Log was downloaded from testing, I intermittently get prompted to update from devel (which results in the issues we discussed).
Glad it works this way, though. If it's the same app, and I enable a certain repository, I should be able to download an update if one is available even if it's through a different repository than the one I obtained my app through.
Hadn't seen it.. Weird, though, that the "fix" is so simple and wasn't implemented by default. Oh well..
Anyway, probably more important than displaying end time for a call is the duration of said call (preferably in human-readable form.. 1:20 as opposed to 80seconds). Of course, if we could have all of it, start;end;duration, even better.
The talk says adding those triggers is relatively safe.. There doesn't seem to be any system-default triggers and running that batch command resets the list so unless some other app decides to overwrite them, it should be relatively safe putting that into your app's pre- or post-installation scripts.
Hadn't seen it.. Weird, though, that the "fix" is so simple and wasn't implemented by default. Oh well..
Anyway, probably more important than displaying end time for a call is the duration of said call (preferably in human-readable form.. 1:20 as opposed to 80seconds). Of course, if we could have all of it, start;end;duration, even better.
The talk says adding those triggers is relatively safe.. There doesn't seem to be any system-default triggers and running that batch command resets the list so unless some other app decides to overwrite them, it should be relatively safe putting that into your app's pre- or post-installation scripts.
Human readable format shouldn't be too much extra effort so would be ok. Although, I probably won't put the triggers as part of my install script, as I'd prefer to have that left somewhat separate to allow people to choose if they want to try it just in case it causes issues.
Maybe I could include a script that is easy to run that can be used to set up the triggers