Package Details: cursor-bin 1.1.5-1

Git Clone URL: https://aur.archlinux.org/cursor-bin.git (read-only, click to copy)
Package Base: cursor-bin
Description: Cursor App - AI-first coding environment
Upstream URL: https://www.cursor.com/
Licenses: custom:proprietary
Submitter: g.schulz
Maintainer: g.schulz
Last Packager: g.schulz
Votes: 55
Popularity: 8.29
First Submitted: 2024-06-09 14:27 (UTC)
Last Updated: 2025-06-21 21:05 (UTC)

Pinned Comments

g.schulz commented on 2025-05-17 08:01 (UTC) (edited on 2025-05-18 10:16 (UTC) by g.schulz)

For anyone who want's to contribute a PR, this is the repo: https://github.com/Gunther-Schulz/aur-cursor-bin-updater

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 18 Next › Last »

bermudi commented on 2025-04-03 18:48 (UTC) (edited on 2025-04-03 18:48 (UTC) by bermudi)

cleanbuild does work for me when updating to an AUR revision (-2) using yay

iptoux commented on 2025-04-03 18:44 (UTC)

Hey @g.schulz

running into same problems when using pamac, BUT, there are no problems when using yay -Syu in terminal.

bermudi commented on 2025-04-03 18:04 (UTC)

@g.schulz yup, using yay to handle updates.

I will check if cleanbuild helps and get back to report

Stonemincan commented on 2025-04-03 16:32 (UTC)

@g.schulz, I use pamac on Arch and I get the errors for every update that is the same version number, like bermudi.

eriknelson commented on 2025-04-03 13:45 (UTC) (edited on 2025-04-03 13:45 (UTC) by eriknelson)

I also hit a checksum failure, although I think I know why. I use auracle for aur pkg updates. I'm assuming that I caught the updated PKGBUILD with a new checksum, but it might have cached the binary thinking it's the same one, attempted to update, and failed the checksum due to the new one. I destroyed the directory and checked it out fresh, forced a new binary download that matched on the checksum and I was good to go:

# makepkg -si   
==> Making package: cursor-bin 0.48.7-2 (Thu Apr  3 09:38:00 2025)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...                                                                                                                                                                                           
  -> Found cursor-bin-0.48.7.AppImage                                                                                                                                                                               
  -> Found cursor.png                                                                                                                                                                                               
  -> Found cursor-bin.desktop.in
  -> Found cursor-bin.sh
==> Validating source_x86_64 files with sha512sums...
    cursor-bin-0.48.7.AppImage ... FAILED
    cursor.png ... Passed                                                                                                                                                                                           
    cursor-bin.desktop.in ... Passed                                                                                                                                                                                
    cursor-bin.sh ... Passed                                                                                                                                                                                        
==> ERROR: One or more files did not pass the validity check!

A question for everyone: I recently added to the PKGBUILD release script functionality that skips a build if it's a downgrade (see my previous comment). Should I revert that change and follow Cursor's releases exactly?

@g.schulz: I can see an argument for both, their releases are definitely a bit nonsensical, but of course I think the team would probably consider this method of updating to be non-public with no real guarantees. I would vote for identical cursor releases; I suspect they're reverting issues or pushing changes that may break Arch users if we're utilizing a binary that doesn't match what they currently expect. My 2c.

g.schulz commented on 2025-04-03 09:16 (UTC) (edited on 2025-04-03 09:18 (UTC) by g.schulz)

@bermudi hi, I just upgraded to "0.48.7-2" fine without any failed checksum message. Are you using yay or how do you upgrade? If so, did you choose "[A]ll" for "Packages to cleanBuild?"? I had to do that once for 0.48.6-2 but for 0.48.-2 I did not although I am not sure why as that was the first time I ever encountered such an issue upgrading.

Is anyone else having similar issues with upgrading?

About multiple releases by cursor using the same version number, I really wonder why they do that. For example we currently have two separate binaries for 0.48.7:

https://downloads.cursor.com/production/66290080aae40d23364ba2371832bda0933a3641/linux/x64/Cursor-0.48.7-x86_64.AppImage

https://downloads.cursor.com/production/1d623c4cc1d3bb6e0fe4f1d5434b47b958b05876/linux/x64/Cursor-0.48.7-x86_64.AppImage

Looking back at the commit history for the PKGBUILD I can see that cursor does this quite often, sometimes even reverting to a previous version (as they did on monday) only to re-release a never version again but with a different binary. All a bit confusing.

A question for everyone: I recently added to the PKGBUILD release script functionality that skips a build if it's a downgrade (see my previous comment). Should I revert that change and follow Cursor's releases exactly?

bermudi commented on 2025-04-03 01:35 (UTC)

0.48.7-2

==> Validating source_x86_64 files with sha512sums...
    cursor-bin-0.48.7.AppImage ... FAILED

@g.schulz first of all, thanks for maintaining.

0.48.7-1 did install for me, but I am getting prompted to update and that's when checksum is failing. Same thing happened with 0.48.6-2, 0.48.6-1 did install fine, later I got prompted with 0.48.6-2 update and checksum failed, a few hours later I got prompted for 0.48.6-3 and it also failed the checksum. Looks like the first version (AUR versions ending with -1) are being created correctly but later in the day updates to those releases are being created with an invalid checksum (AUR versions -2, -3). Like you mention, this is probably because Cursor is making different releases with the same version number

Hope I'm making sense trying to explain

g.schulz commented on 2025-03-31 22:10 (UTC) (edited on 2025-04-01 11:56 (UTC) by g.schulz)

@bermudi not sure why but about an hour ago Cursor's api seemingly briefly returned a previous version of Cursor as the latest one. I added a workaround for my PKGBUIL update script so that in the future it will only update the PKGBUILD if the version reported from the api is newer than the current one. Hopefully that will circumvent similar issues in the future. The PKGBUILD is up-to-date now but if there are still problems upgrading you can do 1) if you use yay select "[A]all" when it asks about build files or 2) clone the repo and run "makepkg -si". This way you should not get the failed checksum message.

Another thing i noticed, as far as I can tell Cursor actually published 0.48.6 twice today with different binaries (different checksums) but the same download link. I am unclear why they were doing that. But it does seem likely that something wasn't working properly with their release mechanism today I assume.

In summary Cursor was publishing 0.48.6 variant A, then 0.48.6 variant B, then 0.48.4 and now 0.48.6 variant B again. All of this happened within 24hrs. I manually bumped the pkgver to 3 so that it's clear which is the most recent one.

bermudi commented on 2025-03-31 20:43 (UTC) (edited on 2025-03-31 20:43 (UTC) by bermudi)

0.48.6-2

==> Validating source_x86_64 files with sha512sums...
    cursor-bin-0.48.6.AppImage ... FAILED
    cursor.png ... Passed
    cursor-bin.desktop.in ... Passed
    cursor-bin.sh ... Passed
==> ERROR: One or more files did not pass the validity check!

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 18 Next › Last »