Active Topics

 


Reply
Thread Tools
Posts: 114 | Thanked: 409 times | Joined on Jun 2011 @ Germany
#221
Just an idea... Wouldn't it be possible to depend the rpms to sailfish-version, so that they would be automatically uninstalled when upgrading?


Edit: Or a new meta-rpm that depends on sailfish-version and disables all patches in pre-uninstall script. So you don't have to reinstall the patches every time, but the meta-rpm has to be installed again...

Gesendet von meinem Jolla C mit Tapatalk

Last edited by ejjoman; 2016-07-30 at 09:03.
 

The Following 3 Users Say Thank You to ejjoman For This Useful Post:
eson's Avatar
Posts: 363 | Thanked: 1,375 times | Joined on Nov 2015 @ Sweden
#222
Originally Posted by mikecomputing View Post
If they do that next update you will say. "Why can't the upgrade tool remove the patches before upgrade"
No, I wouldn't... promise! But it would be a great feature.
 

The Following User Says Thank You to eson For This Useful Post:
pichlo's Avatar
Posts: 6,447 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#223
Originally Posted by ejjoman View Post
Just an idea... Wouldn't it be possible to depend the rpms to sailfish-version, so that they would be automatically uninstalled when upgrading?
Ancelad has been doing that in his patches for ages. I took it a step forward in mine and make them depend not on a specific OS version but on the version of the patched component. That way they will get automatically unapplied and uninstalled but only if the relevant component is being updated.

It is not foolproof. There have been cases when the package was updated but the exact QML file that was being patched remained the same. In such a case an automatic uninstallation was an overkill but I still think it is better than risking leaving patches hanging around.
__________________
Русский военный корабль, иди нахуй!
 

The Following 13 Users Say Thank You to pichlo For This Useful Post:
Posts: 123 | Thanked: 268 times | Joined on Dec 2009 @ Helsinki, Finland
#224
Damn, it appears that STK does not work anymore in 2.0.2.48. I know there has been issues before, but so far it worked for me just fine. Have to investigate further. I could revert back, but I think it is easier just to switch the sim card to a J1 with previous OS version (I happen to have such a beast).

Does anyone know how to see STK's presence from command line? Logs or anything?
 

The Following User Says Thank You to Tsippaduida For This Useful Post:
Posts: 123 | Thanked: 268 times | Joined on Dec 2009 @ Helsinki, Finland
#225
Worked in previous version as expected. Now back in original phone and it seems to be working again. Just airing the sim card seems to have fixed my issues.

Usually I have an "application" named after my operator with a picture of a sim card as a last application in the list. That was also missing when STK did not work. Now that the sim popped back in, I see that application again.
 

The Following 3 Users Say Thank You to Tsippaduida For This Useful Post:
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#226
I was happy to notice that this time dpurgin's Call Recorder worked out-of-the-box with Aurajoki.
On most previous updated I have had to recompile and reinstall it for the new OS version
 

The Following 2 Users Say Thank You to juiceme For This Useful Post:
pichlo's Avatar
Posts: 6,447 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#227
Originally Posted by juiceme View Post
I was happy to notice that this time dpurgin's Call Recorder worked out-of-the-box with Aurajoki.
On most previous updated I have had to recompile and reinstall it for the new OS version
Whaaat????

NEVER had to recompile anything. Call Recorder has always worked for me OOTB, except for a single brief episode when one Sailfish update broke it.
__________________
Русский военный корабль, иди нахуй!
 

The Following 3 Users Say Thank You to pichlo For This Useful Post:
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#228
Originally Posted by pichlo View Post
Whaaat????

NEVER had to recompile anything. Call Recorder has always worked for me OOTB, except for a single brief episode when one Sailfish update broke it.
Odd. Do you compile it yourself or use the binary from openrepos?

There has been at least 2 updates when I had to build it with a newer devkit when the OS revision changed.
And at least once there was a change in the code itself (and dpurgin updated the git repo)
 
pichlo's Avatar
Posts: 6,447 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#229
Originally Posted by juiceme View Post
Odd. Do you compile it yourself or use the binary from openrepos?
I said I never recompiled anything, did I not? That means only binaries from repos.

Yes, there was one brief period when an OS update broke it but dpjrgin fixed it in a week or two. That's all I remember.
__________________
Русский военный корабль, иди нахуй!
 

The Following 2 Users Say Thank You to pichlo For This Useful Post:
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#230
Originally Posted by nthn View Post
Jolla shouldn't have to bother informing users about third party scripts that will cause trouble with those third party scripts. Even so, they do, it's always mentioned in the release notes.
Yeah, I think they already go quite out of their way by mentioning scripts & co in the release notes, which is nice.

But I don't agree that Jolla shouldn't bother doing this - I can't help myself but think about patches mostly as a temporary solution for the following two problems:
  1. closed source GUI components
    I think that many patches could be "upstreamed" and maintained as (optional ?) features of the GUI by the community if the respective components were open source & with an upstream where to send patches/pull requests.
  2. insufficient pluggability in the GUI
    Stuff too radical/too big to integrate directly with the GUI components themselves could make use of suitable hooks, plugin interfaces, DBUS API to interact with the system when installed by the user (eq. they would not be part of the "default firmware" and would be installed by the user.

    There are already some GUI extensions interfaces (sharing interface, telepathy plugins, etc.), but they are IMHO currently quite lacking & are often undocumented when they do exist.

So until these two issues are solved, Jolla should certainly care about patches & the surrounding community as its basically just a (temporary ?) workaround for features lacking in the platform (Sailfish OS) they are trying to develop.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
 

The Following 5 Users Say Thank You to MartinK For This Useful Post:
Reply

Tags
intex, jolla, sailfishos, sfo update, sfos2, update


 
Forum Jump


All times are GMT. The time now is 10:29.