Arch Linux User Repository

What worked for me was

pamac checkupdates -a --devel
pamac upgrade -a --devel

Where -a stands for aur and --devel for development packages.

Since the --devel flag checks if behind the development packages (like "*-git" packages) there are any newer versions, it will update to the latest version of the package in git and not require and update on the aur listing

Please stop flagging this AUR as out-of-date unless you have tried these:

If you use a proper AUR helper (e.g paru, yay) this AUR will be use the latest commit of the Github repo. If you use pamac, it will not update based on the latest commit automatically and you should do pamac install --upgrade flameshot-git to force it to check for upgrades. Therefore, this AUR cannot become out-of-date unless the Github URL or dependencies get out of date.

I've decided to repost my comment as I just kept editing minor things to minimize the amount of implications & assumptions I was making - I was also writing it at work, so that context switching probably also didn't help...

@mehrad Sorry for the late reply, but I haven't enabled notifications for this thread because my message was a mere comment & I didn't even expect a reply... it definitely was not a punch - I'm sorry if it felt like one. I just saw you frequently marking this package as out-of-date, even though it wasn't, and thought I could clear up the confusion.

AFAIK, the pkgver variable is not ever preferred over the pkgver() function - at least, it is not stated explicitly anywhere, and most AUR helpers I've tried (yay, yaourt & pamac) don't prefer it either. Personally, I understand it as a mere convenience for people using AUR, so that they know what version they are getting & so that AUR helpers can automatically determine when a package is out of date.

I do agree, that if you want to get automatic updates (via -Syyu, etc) when a new git commit is available, you will need to update the pkgver variable of this package, otherwise, you'd need to manually run the update. Sadly I don't think there is a way to automate that, so that's why I believe package updates like the "Update to release 0.8.3" you were mentioning are still welcome - but I have seen up-to-date -git packages with updates as far back as few years (none come to mind rn).

edit: nvm.. It's been a while and I completely forgot about the --devel flag.. That does automate it, meaning this entire conversation was borderline useless.

Maintainer update:

@Feresey posted a notice on Flameshot Slack that he wants to throw this AUR and I stepped up and "adopted" it. I'm still in the early learning curve of maintaining the AUR, but similar to @Feresey I am also working close with the devs of Flameshot.

@niraami First and foremost, I'm not an expert and the following is my understanding of the situation. I used to had the flameshot installed through this AUR and then I realized it does not update. That's when I posted the comment. My current hypothesis is that the AUR will install the latest version if this is your first time installing this AUR, but it will never update despite of how far the git repo is and how many versions have been released.

Now, let's get down to some facts:

1. on line 7 of the PKGBUILD it is clearly stated that the commit it should point to is "ceb51a9" which means it does not point to "HEAD". Let's try that, shall we? https://github.com/flameshot-org/flameshot/commit/ceb51a9 As one can see, the "ceb51a9" commit is made on "Sep 28, 2020"

2. even when you query the AUR you will get:

❯  pamac search flameshot-git
flameshot-git                                                                   r707.ceb51a9-1  AUR
Powerful yet simple to use screenshot software

1. When you install it via AUR helper, the AUR helper of your choice will clone the repo, and if it respects the PKGBUILD it should immediately checkout to "ceb51a9" and the stare the build process. This is because the build instructions and dependencies might have change from the specified commit (in our case "ceb51a9") to the "HEAD" (in our case "d9b9049"). Now, when I tried your hypothesis with pamac (my AUR helper of choice), I saw the following (note the second line and second to the last line):

Building flameshot-git...
==> Making package: flameshot-git r707.ceb51a9-1 (Thu 25 Feb 2021 12:55:39 PM EET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Cloning flameshot git repo...
Cloning into bare repository '/var/tmp/pamac-build-mehrad/flameshot-git/flameshot'...
remote: Enumerating objects: 98, done.
remote: Counting objects: 100% (98/98), done.
remote: Compressing objects: 100% (80/80), done.
remote: Total 14603 (delta 40), reused 31 (delta 14), pack-reused 14505
Receiving objects: 100% (14603/14603), 12.76 MiB | 2.47 MiB/s, done.
Resolving deltas: 100% (10367/10367), done.
==> Validating source files with md5sums...
flameshot ... Skipped
==> Removing existing $srcdir/ directory...
==> Extracting sources...
-> Creating working copy of flameshot git repo...
Cloning into 'flameshot'...
done.
==> Starting pkgver()...
==> Updated version: flameshot-git r1253.d9b9049-1
==> Starting build()...

The AUR helper has decided on its own to go with "d9b9049". This might be due to the md5sums=('SKIP') in PKGBUILD or poor implementation of AUR helper or even an AUR helper that tries to be smart.

1. if the package didn't need to be updated, why on earth the AUR maintainers have "Update to release 0.8.3" on "2020-09-28" see the log

Now, back to my hypothesis, perhaps you just installed this AUR and you didn't update from 0.8.3 to 0.9.0. Now, regarding your comment about AUR helper cache, when you have the AUR installed, it will show you "flameshot-git r1253.d9b9049-1" but when you remove the AUR and search the AUR again (e.g through pamac search flameshot-git) you will again get r707.ceb51a9-1. I encourage you to also try that.

P.s: This is a civilized community and it is accepted that people make mistakes, no need to throw punches.

Contrary to what @mehrad is saying, this package is not out of date - git packages stay up to date by cloning the master repo on each install, so there is no need to update this package manually (most of the time). Run flameshot -v to see for yourself - returns v0.9.0 for me. Or check the aur-helper cache, to see that the latest flameshot commit is actually being used.

@Feresey The latest Flameshot stable release is 0.8.5 and it was released over a month ago. Would it be possible to update the AUR?

https://github.com/zsh-users/zsh-completions/issues/762

Until this is fixed, you can use the --overwrite flag when installing.

How can I manually remove the zsh-completions?

conflicting files:
- flameshot-git: /usr/share/zsh/site-functions/_flameshot already exists in filesystem (owned by zsh-completions)

error: failed to commit transaction (conflicting files)
flameshot-git: /usr/share/zsh/site-functions/_flameshot exists in filesystem (owned by zsh-completions)
Errors occurred, no packages were upgraded.

Since flameshot will provide its own zsh completions, we should wait until the official release and create a ticket for zsh-completions to delete on their side.

@Feresey The build should be stable now. Let me know if you have any build issues and I'll fix it ASAP.