SailJail preparations #43
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "nephros/harbour-nextcloud-talk:sbox"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
See #44
SailJail preparationsto WIP: SailJail preparations3a30802740
to5d8f70587b
eb06414af0
to612dae951d
d6ba934b3e
to89b40366f8
WIP: SailJail preparationsto SailJail preparations@ -0,0 +3,4 @@
X-Nemo-Application-Type=silica-qt5
Icon=harbour-nextcloud-talk
Exec=/usr/bin/harbour-nextcloud-talk
Name=Nextcloud Talk
does it make sense to hint here that it's the jailed version? Or, other way, indiciated in the unjailed version that it is accordingly? e.g. "Nextcloud Talk ([Un]jailed)"
@ -21,0 +25,4 @@
newDbDir.mkpath(newDbDir.path());
qDebug() << "dir created " << newDbDir.path();
if(oldDb.exists()) {
oldDb.copy(newDbDir.path() + "/talk.db" );
let's move it instead of leaving stale files around
I'm not entirely sure the old location is writeable while jailed, but yeah, will try to delete the file.
I wonder if all this migrating is necessesary at all.
AFAICS only the last message markers are stored there - are they critical?
Because otherwise we could drop all that migrating stuff and just use the new location (creating a new empty DB at next launch).
In nowadays Talk versions probably not anymore, any unread ones should be displayed now. When using more clients, like web and mobile, it actually can be quite annoying when a big number of posts has to be fetched first when it was not opened on this client for a while. So I was already thinking to get rid of the marker in general, with some testing to ensure all new message are being fetched (for pulling older messages is not implemented).
Also in that cast it would be good to remove the table. For it probably is not writable anyway, an info in the app description (storage page) would be sufficient.
7950e4be10
to4d0b9a1fef
570828aa7c
todcf2f524d7
SailJail preparationsto WIP: SailJail preparationsac87215ff7
to59eac47638
59eac47638
tobe0f9bd2ad
Sorry for the noise.
I think this works correctly now.
WIP: SailJail preparationsto SailJail preparationsSailJail preparationsto WIP: SailJail preparationsbe0f9bd2ad
to0559bf4c7c
WIP: SailJail preparationsto SailJail preparationsNothing to apologize for! I am absolutely happy that you pick up on it!
@ -67,2 +70,4 @@
%post
# >> post
# Secrets permission is only in SFOS >= 4.4
if [ $(awk -F= '/^VERSION_ID/ {gsub(/\./,"") ; print $2}' /etc/os-release) -lt 44000 ]; then
good one!
@ -21,0 +26,4 @@
qDebug() << "success, removing old";
oldDbPath.remove();
QDir().rmpath(newDbDir.path());
} else { qCritical() << "copying failed"; }
style: imo better readable (and editable) to spread it out into three lines. Whitep
Generally good to merge, if you like to check out #43 (comment) you can try this out, but not a necessity at all. Good to merge like this already.
1636211238
to384d6f52da
I'll leave it as is.
Copy & remove is the cleanest. The rmdir() doesn't work (old dir remains) - I think that is because there is something mounted on it (through sailjail) but not sure.
Dropping the database completely is too big a change, and maybe there is some other use for it in the future.