[kde] [Bug 465764] Tool to see Network Shares in use
https://bugs.kde.org/show_bug.cgi?id=465764 --- Comment #2 from Kjetil Kjernsmo --- It really needs to have other network protocols too, like NFS and SSHFS, to be useful. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 465764] New: Tool to see Network Shares in use
https://bugs.kde.org/show_bug.cgi?id=465764 Bug ID: 465764 Summary: Tool to see Network Shares in use Classification: I don't know Product: kde Version: unspecified Platform: Ubuntu OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: kje...@kjernsmo.net Target Milestone: --- SUMMARY The most problematic thing I find is that when I leave home, something freezes due to network shares still being used by something. There are numerous issues around related to this, like #316655, #433611, #464135, #454722 etc. It would be very useful to tell what has open files on the network shares STEPS TO REPRODUCE 1. Open some file on a network share with an application 2. Attempt to unmount the network share 3. Or just try to take the network down OBSERVED RESULT Whatever had the file open hangs, or it is impossible to take network down, or to turn off the system until the share times out. EXPECTED RESULT Have a tool that kind simply show me what applications have files on the network share open so that I can close them manually. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 146865] MYSQL : networked and multi-users database backend
https://bugs.kde.org/show_bug.cgi?id=146865 --- Comment #12 from Kjetil Kjernsmo --- (In reply to Dan Fallon from comment #11) > While this seems like a cool idea, it seems like you didn't > read the rest of the thread before necro'ing this feature request to promote > a project you work on... > > https://solidproject.org/team#kjetil-kjernsmo With all due respect, Dan, but if you read the thread, you'd see that I was participating in this thread 15 years ago, and at that time, there were several who were open to the consideration that using RDF might be the right way to implement the use cases behind this issue. Solid basically provides the technical infrastructure to use RDF this way. I was using Digikam with a collection on an NFS share when this issue was created, and with a remote MySQL database for the last decade. Recently, I have set up MySQL so that my daughter can use Digikam on a different machine, but she hasn't done it a lot and certainly not concurrently with me. I am aware that this can be done right now, but for more advanced use cases, I would probably look to other technologies. I think your comment was rather undue, as my comment was a follow-up from the discussion that happened 15 years ago. -- You are receiving this mail because: You are watching all bug changes.
[kfile] [Bug 316655] Dolphin freezes when a network [cifs] mount is lost
https://bugs.kde.org/show_bug.cgi?id=316655
Kjetil Kjernsmo changed:
What|Removed |Added
CC||kje...@kjernsmo.net
--- Comment #25 from Kjetil Kjernsmo ---
FWIW, for me, the NFS server is stable, but I couldn't bring the laptop along
without jumping a lot of hoops, and I made this a lot less annoying by using a
NetworkManager dispatcher-script:
#!/usr/bin/perl
use strict;
use warnings;
# Find the connection UUID with "nmcli con show" in terminal.
# All NetworkManager connection types are supported: wireless, VPN, wired...
#!/usr/bin/perl
use strict;
use warnings;
# Find the connection UUID with "nmcli con show" in terminal.
# All NetworkManager connection types are supported: wireless, VPN, wired...
use Data::Dumper;
my %connections = (
'some-uuid => 'ethernet',
'some-other-uuid' => 'wifi'
);
my ($name, $event) = @ARGV;
my $conn = $ENV{'CONNECTION_UUID'};
print "Connection: $conn \nName: $name\nEvent: $event\n";
if ($event eq 'up') {
# New connection is coming up
if ($connections{$conn}) {
# We are at home
unless (mounted_ok()) {
system("coming-home.sh");
}
}
}
if ($event eq 'connectivity-change' && $ENV{'CONNECTIVITY_STATE'} eq 'NONE') {
if (mounted_ok()) {
system("leaving-home.sh");
}
}
sub mounted_ok {
my $home_mounted = 0;
open(FH, '<', '/proc/mounts') || die "Could not read mounts";
while () {
if (m/site nfs/) {
$home_mounted = 1;
last;
}
}
Where the two shell scripts do the actual mounts/unmounts (and other
housekeeping tasks in my case).
With this, I only need to disconnect the network before I pull the plug.
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 146865] MYSQL : networked and multi-users database backend
https://bugs.kde.org/show_bug.cgi?id=146865 Kjetil Kjernsmo changed: What|Removed |Added CC||kje...@kjernsmo.net --- Comment #10 from Kjetil Kjernsmo --- This is now becoming possible within the Solid Project, https://solidproject.org/ . We recently published the 0.9 version of the protocol spec: https://solidproject.org/TR/protocol The way this could be done on Solid is to create an add-on that it is a Solid client. That client has to have a concept of users and authorization policies, but as a first iteration, it could be done as simple as "just me" and "everyone else", that would still be useful, I think. The images themselves would be PUT to the server, and the metadata would be written along with it in what is in Solid an auxiliary resource, specifically a Resource Description. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 51517] Autoadd addresses onto spam filter's whitelist
https://bugs.kde.org/show_bug.cgi?id=51517 --- Comment #10 from Kjetil Kjernsmo --- It isn't resolved in the sense that it isn't a problem anymore. However, in the current environment, there isn't a realistic fix. It might become realistic if https://solidproject.org/ or through some custom API. I guess this could be resolved as WONTFIX, and then we can return into it if it becomes a possibility. -- You are receiving this mail because: You are watching all bug changes.
[libkgapi] [Bug 439285] Bad request, Google replied "Contacts API is being deprecated"
https://bugs.kde.org/show_bug.cgi?id=439285 Kjetil Kjernsmo changed: What|Removed |Added CC||kje...@kjernsmo.net -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 417464] Limit battery charging to e.g. 80% to improve battery lifetime
https://bugs.kde.org/show_bug.cgi?id=417464 Kjetil Kjernsmo changed: What|Removed |Added CC||kje...@kjernsmo.net -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 417464] New: Limit battery charging to e.g. 80% to improve battery lifetime
https://bugs.kde.org/show_bug.cgi?id=417464 Bug ID: 417464 Summary: Limit battery charging to e.g. 80% to improve battery lifetime Product: Powerdevil Version: unspecified Platform: Debian stable OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: kje...@kjernsmo.net Target Milestone: --- SUMMARY There's an interesting article on prolonging battery life at: https://batteryuniversity.com/index.php/learn/article/how_to_prolong_lithium_based_batteries They recommend: "To make this feature user-friendly, a device should feature a “Long Life” mode that keeps the battery at 4.05V/cell and offers a SoC of about 80 percent. One hour before traveling, the user requests the “Full Capacity” mode to bring the charge to 4.20V/cell." So, it is basically my wish that this is implemented in KDE. You can't do that now, right? If not, it seems like Powerdevil would be a nice place to have a setting that limits the charge to a certain percentage of full, and then possibly a plasmoid or something that makes it really easy to override that like they suggest. If I understand it correctly, there is stuff in TLP that can help with this, at least on some system, but I don't know if that's the appropriate way to implement it. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 411480] Problems with database migration on remote host
https://bugs.kde.org/show_bug.cgi?id=411480 --- Comment #3 from Kjetil Kjernsmo --- Indeed, this was a pure database migration issue. I had to start from scratch, remove most of the backup that was related to the mysql database. It eventually worked, but was painful. You may close this if you wish. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 411480] New: Problems with database migration on remote host
https://bugs.kde.org/show_bug.cgi?id=411480 Bug ID: 411480 Summary: Problems with database migration on remote host Product: digikam Version: 5.9.0 Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Database-Mysql Assignee: digikam-bugs-n...@kde.org Reporter: kje...@kjernsmo.net Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. Have a version 8 database on a different host than the desktop where Digikam reside 2. Launch digikam 5.9.0 3. Observe console output OBSERVED RESULT Digikam opens a dialog saying database migration failed, and that I should file a bug report with the output from the console. Here it is: digikam.general: AlbumWatch use QFileSystemWatcher digikam.general: Database Parameters: Type: "QMYSQL" DB Core Name: "digikam" DB Thumbs Name: "thumbnails_digikam" DB Face Name: "face_digikam" Connect Options: "" Host Name:"robin" Host port:3306 Internal Server: false Internal Server Path: "" Internal Server Serv Cmd: "" Internal Server Init Cmd: "" Username: "kjetil" Password: "XXX" digikam.dbengine: Loading SQL code from config file "/usr/share/digikam/database/dbconfig.xml" digikam.dbengine: Checking XML version ID => expected: 3 found: 3 digikam.coredb: Core database: running schema update digikam.coredb: Core database: have a structure version 8 digikam.coredb: Core database: makeUpdates 8 to 9 digikam.dbengine: Failure executing query: "" Error messages: "QMYSQL: Unable to execute query" "Column count of mysql.proc is wrong. Expected 21, found 20. The table is probably corrupted" 1805 2 Bound values: () digikam.dbengine: Error while executing DBAction [ "UpdateSchemaFromV7ToV9" ] Statement [ "\nDROP PROCEDURE IF EXISTS drop_foreign_key;\n " ] digikam.coredb: Core database: schema update to V 9 failed! digikam.coredb: Core database: cannot process schema initialization KMemoryInfo: Platform identified : "LINUX" KMemoryInfo: TotalRam: 8291205120 digikam.general: Allowing a cache size of 200 MB QThreadStorage: Thread 0x7fec65146bc0 exited after QThreadStorage 10 destroyed EXPECTED RESULT That Digikam would start and migrate the database. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
