Search Criteria
Package Details: manictime-bin 1.3.7-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/manictime-bin.git (read-only, click to copy) |
---|---|
Package Base: | manictime-bin |
Description: | ManicTime automatically records your computer usage. |
Upstream URL: | https://www.manictime.com/linux/download |
Licenses: | custom |
Submitter: | 1994rstefan |
Maintainer: | Jenzaah |
Last Packager: | Jenzaah |
Votes: | 4 |
Popularity: | 0.000090 |
First Submitted: | 2019-02-25 15:32 (UTC) |
Last Updated: | 2023-03-17 12:27 (UTC) |
Latest Comments
ardency commented on 2022-05-21 13:05 (UTC)
Sorry for not noticing your comment, I hadn't logged into that email account in months. Thanks for taking this over and fixing it!
Jenzaah commented on 2022-04-18 07:05 (UTC)
I've created a working PKGBUILD. Can this be updated?
https://gist.github.com/JensVanhooydonck/b21928b40f5e50e37b760ddc7bf3792f
Thenujan commented on 2021-10-09 15:03 (UTC) (edited on 2021-10-11 10:18 (UTC) by Thenujan)
Doesnt work on manjaro . opening the app from the launcher does nothing rather than loading for a while
ardency commented on 2020-10-23 21:16 (UTC)
This package is a quite broken.
Running
manictime
(/usr/bin/manictime
->/opt/manictime/manictime
) returns immediately without launching the program. This is a script that tries to executeManicTime
from the same directory it's invoked from. Readingnohup.out
, you'll see that this doesn't exist, because that'd be/usr/bin/
, while the installation directory is/opt/manictime/
Line 7 should look like this after install:
SCRIPTPATH="$( cd /opt/manictime >/dev/null 2>&1 ; pwd -P )"
-- but you'd want to do that with the appropriate variable inPGKBUILD
.Executing
/opt/manictime/ManicTime
manually spits back:rpath
is explicitly set to an invalid path, but this is a red herring. ReadingManicTime.deps.json
tells us that the assembly it can't find is a 'native' runtime, and indeed, they aren't included with the other libraries to be dynamically linked in/opt/manictime/Libs
.The files it needs are included with the
dotnet-runtime
package in repos, but changing the binary ELFrpath
to include where they reside doesn't resolve the error. I'm not familiar with .NET apps at all; maybe the manifest could be modified to handle this somehow. This package ought to be in the dependencies.I ended up hacking around this problem by symlinking the following assemblies from
/opt/dotnet/shared/Microsoft.NETCore.App/3.0.0-rc1-19456-20/
into/opt/manictime/Libs/runtimepack.Microsoft.NETCore.App.Runtime.linux-x64/3.1.3
:Sorry I couldn't help more. Maybe the people over on the forum could help you out with additional improvements!