Package Details: stm32cubeide 1.15.1-1

Git Clone URL: https://aur.archlinux.org/stm32cubeide.git (read-only, click to copy)
Package Base: stm32cubeide
Description: Integrated Development Environment for STM32
Upstream URL: https://www.st.com/en/development-tools/stm32cubeide.html
Keywords: arm cortex cortex-m cube cubeide stm32
Licenses: custom:SLA0048
Submitter: kumen
Maintainer: kumen
Last Packager: kumen
Votes: 35
Popularity: 0.97
First Submitted: 2019-05-02 15:05 (UTC)
Last Updated: 2024-04-27 13:10 (UTC)

Pinned Comments

kumen commented on 2023-03-19 13:14 (UTC) (edited on 2023-03-19 13:17 (UTC) by kumen)

STM32CubeIDE is now run by executing stm32cubeide_wayland official script. If you have issues related to run environment, try to edit /usr/share/applications/stm32cubeide.desktop file and uncomment one of commented out Exec=... lines and comment out currently used one. After making changes to stm32cubeide.desktop run update-desktop-database as root to apply changes.

Discussion about this Eclipse issues is here: https://github.com/eclipse-platform/eclipse.platform.swt/issues/158

Latest Comments

« First ‹ Previous 1 .. 4 5 6 7 8 9 10 11 12 13 14 Next › Last »

kumen commented on 2021-01-13 21:05 (UTC) (edited on 2021-01-13 21:06 (UTC) by kumen)

I don't have any idea how this PKGBUILD could even create folder /opt/st/stm32cubeide_1.5.0/ and use it for installation or create st-stm32cubeide-1.5.0.desktop file.
I tried to rebuild version 1.5.0-3 and everything is OK.

Sabu commented on 2021-01-13 19:13 (UTC)

Version 1.5.0 of stm32cubeide was installed by pamac or yaourt, I´m really sure. I've never installed any package without these installers.

kumen commented on 2021-01-13 18:02 (UTC)

Version 1.5.0 of stm32cubeide was probably installed directly without making package from aur, right? If so, you must uninstall it manually.

Sabu commented on 2021-01-13 17:40 (UTC) (edited on 2021-01-13 17:55 (UTC) by Sabu)

Few days ago I´ve downloaded and reinstalled stm32cubeide (ver. 1.5.1) and found out that the installation directory differs from previous installation (ver. 1.5.0). The reason for that was that the newer version did not run by clicking on the desktop icon, the older version was starting up instead. While version 1.5.0 still exists in /opt/st/stm32cubeide_1.5.0/ the newer reinstalled version is now in /opt/stm32cubeide/. I've also took a closer look into the installed startup-files st-stm32cubeide-1.5.0.desktop and stm32cubeide.desktop, both located in /usr/share/applications/. If I'm right, the newer version of this file contains incomplete entries. You can see both files side by side here: https://abload.de/img/screenshot_20210113_1l8koq.jpg

But my main question about this is, how can I remove the older version thus ver. 1.5.0?

kumen commented on 2021-01-06 21:23 (UTC)

Downloading and reinstalling is single one option. Update through IDE is not possible because of low user privileges. Allowing user updates through IDE will cause lost of files tracking and next big update will be with problems.

Or is there solution how to prevent lost of file tracking and allow user updates through IDE?

Sabu commented on 2021-01-06 21:15 (UTC)

How should an update be done? By downloading via the IDE (Help -> Check for Updates) or by downloading and the reinstalling? Or is there another procedure?

kumen commented on 2020-12-08 00:33 (UTC)

Skipped. Thanks for sharing.

Sabu commented on 2020-12-06 22:35 (UTC)

The sha256sum of dm00218346.pdf (en.DM00218346.pdf, sha256=1872c777991c0ee0438d5bf8d47c848da53eeecd8d921b3cb9caf57470f99008) has probably been changed so the installation will fail. My proposal would be to change the checksum to "SKIP" in the PKGBUILD.

yjun commented on 2020-11-09 10:52 (UTC)

convert "${pkgdir}/opt/stm32cubeide/icon.xpm" "${srcdir}/${pkgname}.png"

please add imagemagick to makedepends

yjun commented on 2020-10-19 15:43 (UTC) (edited on 2020-10-19 15:43 (UTC) by yjun)

https://wiki.archlinux.org/index.php/Udev#Installation

udev rules written by the administrator go in /etc/udev/rules.d/, their file name has to end with .rules. The udev rules shipped with various packages are found in /usr/lib/udev/rules.d/

maybe STlink udev rules should move to /usr/lib/udev/rules.d/ as package files

« First ‹ Previous 1 .. 4 5 6 7 8 9 10 11 12 13 14 Next › Last »