Package Details: jetbrains-toolbox

Git Clone URL: (read-only, click to copy)
Package Base: jetbrains-toolbox
Description: Manage all your JetBrains Projects and Tools
Upstream URL:
Licenses: custom:jetbrains
Submitter: freswa
Maintainer: freswa
Last Packager: freswa
Votes: 147
Popularity: 2.90
First Submitted: 2016-05-25 09:43 (UTC)
Last Updated: 2024-04-03 08:02 (UTC)

Latest Comments

1 2 3 4 5 6 .. 12 Next › Last »

teacher4711 commented on 2024-04-03 07:18 (UTC) (edited on 2024-04-03 07:23 (UTC) by teacher4711)

@HydroCarbon It does not matter whether you use an AUR helper or install it manually with git clone and makepkg - a least on my system (latest updates, btrfs).

The package that is downloaded by the PKGBUILD and the one from JetBrains' website are the same in size (71282K). All files pass b2sum.

The generated .zst is merely 85918 bytes and the executable in /opt is just 188392 bytes (an should be 71552K).

HydroCarbon commented on 2024-03-31 01:26 (UTC)

Install it with aur helper. And then download from Unpack tar file. Use mv command to move it to /opt/jetbrains-toolbox/jetbrains-toolbox can fix it.

Furthermore, I noticed that the packages installed using the AUR helper are only a few tens of kilobytes in size.

shubhisroking commented on 2024-03-30 07:56 (UTC)

its broken for me too

HydroCarbon commented on 2024-03-30 00:50 (UTC)

I cannot use it on new arch install(with btrfs) too

MartinX3 commented on 2024-03-28 09:56 (UTC)

Weird, I also use btrfs and it works here.

MightyPork commented on 2024-03-27 22:24 (UTC)

Installing this package gave me a binary that just says "This doesn't look like a squashfs image." when run, something with AppImage. I downloaded the tgz directly from the jetbrains website and that works fine. I'm not saying the package is broken, just didn't work for me on a fresh arch install (with btrfs).

thaiphd commented on 2024-02-22 21:41 (UTC)

b2sum for icon.svg is incorrect so would fail for validity check. The correct b2sum is: 966443013e71ac8474f9c30e06a73cd55c9954ec569b49c46dea5fca17ea6c7ceed1f188ad52f00624bec28c77ae9c232af497b73019f8a3aa2284d45d718fe4

sausix commented on 2023-11-27 18:04 (UTC)

@freswa But shouldn't the desktop file from $HOME being priorized on name conflicting with a desktop file located in /usr/share/applications? At least when not pinning a specific desktop file to a panel of course.

In fact there seem no command line options being present except some appimage related stuff. (strings and grep told me) Maybe there's an ENV switch already. I would recommend to open a bug report. If there's no solution I would at least pin a comment to warn people. Or transition to a kind of preinstaller package. Without an own desktop file to reduce confusement. I will dig into that in future and share my knownledge here. Thanks!

freswa commented on 2023-11-27 17:35 (UTC)

@sausix The problem is the self-updating process of the binary. It will download the latest jar to the user home directory and will create a custom .desktop file in the user desktop-file directory (e.g. ~/.local/share/applications). This will overwrite anything included in the pkg. I don't know a way to disable this behavior. If anyone has an idea, feel free to add a comment here, write me a mail or open a PR. Thank you!

sausix commented on 2023-11-27 17:30 (UTC)

What's the point here? I don't get it. Application says it's outdated but the package is up to date. Since I start the toolbox from command line it's suddenly up to date. But I'm quite sure it's the same executable as in the desktop file.

Can you please pin a comment on how to use this package? Would reduce the outdated flagging at least. Thanks!