Arch Linux User Repository

Thanks to Bevan, we now have a simple and elegant (compared to my attempt) workaround that lets the PKGBUILD download and use the most recent version of maven (currently 3.9.4). Should not need any intervention from you. :)

@Sebastian thanks, its at least a partial fix. if I renamed that folder, version 0.36.1 will start again, after upgrade to 0.37.1 it fails as before.

@richie94 Try to rename $HOME/.eclipse and see whether you can start the program again. I had a similar error in a .eclipse logfile and deleting that folder solved it, but you lose all application preferences.

After i did upgrade to 0.37 in the program, I cannot restart the program and it crashes silently. I just found some logfile in /home/user/.eclipse/276216818_linux_gtk_x86_64/configuration/1547992759371.log which stated multiple exceptions like org.osgi.framework.BundleException: Could not resolve module: org.eclipse.equinox.common and finally java.lang.IllegalStateException: Cant reach the service. ensure that 'org.eclipse.core.runtime' is resolved and started correctly (see 'config.ini')..

In my pacman there was only one warning showing "WARNUNG: Package contains a reference to $srcdir usr/share/portfolio/p2/org.eclipse.equinox.p2.engine/.settings/org.eclipse.equinox.p2.artifact.repository.prefs"

Can anyone help me here?

P.S. If I download prebuild version from github repo all works perfectly.

@Cobra The .desktop file works like a charm. Thanks.

@2ion I've tried today to implement your request using gendesk, but all I've got was an empty directory instead of a .desktop file. I'm certainly doing something wrong, but with room temperatures exceeding 30°C, I have difficulties to think. I'll continue my attempts as soon as my brain doesn't overheat anymore.

Update: it's just 23°C today, and the error was as trivial as easy to find: -dm instead of -Dm. facepalm The .desktop file is now correctly installed in /usr/share/applications.

Hi Cobra, would it be possible to add a .desktop file to the package and install it into /usr/share/applications so that it becomes available in application launchers?

Personally, I'm using the .desktop file here https://gist.github.com/2ion/a71463edc2df529bf23c1060ef1f2f2e, perhaps you could reuse or modify it.

Would appreciate it very much!

@whnr I've experienced occasional minor problems with the binaries, motivating me to pick up the orphaned PKGBUILD in 2015. Compiling portfolio from the sources has worked well for me since then. If the current binaries work well for you, there's nothing to prevent you from using them and the update option integrated into portfolio (Help/Preferences/Updates). Personally, I wouldn't see any benefit of a PKGBUILD initiating a download and reinstall of the binary as compared to this built-in update mechanism of portfolio, but I imagine that it would be rather straightforward to implement this functionality for anybody interested in it.

I'm wondering why is this building the app from source? There is a binary tar available as well. I was wondering, since the install fetched many single sources from the web and moving >350MB around. While it was building I went to the upstream URL and downloaded the binary, tested it (went well) and then waited for the build to finish.

Finally, no more webkitgtk2! From version 0.33, portfolio supports webkit2gtk.

To invoke webkit2gtk in 0.33, delete the line

--launcher.GTK_version 2

in /usr/share/portfolio/PortfolioPerformance.ini. In later versions, this should be the default.

@adlerweb Why didn't I think of that before? Excellent suggestion, thank you very much!