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.

@ian_eo Sorry about the confusion, but because this AUR build the latest commit in the master branch of the github repo, it is actually more misleading to change it to v11, because for instance the most recent commit as of writing this comment is 5ab76e2 which is 19 commits ahead of v11 which was the commit ad1bf28. Basically what I'm trying to say is that this AUR is always up to date as everything is automated. of course the version number (ie. r1629.0fe55916) is updated whenever we modify the PKGBUILD, but even without that, your AUR helper should always be able to check if there is a new commit in Github and build using that.

i hope you match the pkgver similar to what the version releases in github. it makes it easier to identify if there is an update.

ex. from pkgver=r1629.0fe55916 to pkgver=r0.11.

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.

@mehrad you are right, I removed that comment. If you want to go safe, flameshot-0.10.1-1 works. To install it you can go here: https://archive.archlinux.org/packages/f/flameshot/ copy the link and paste in terminal with pacman -U _link_ command

@allexj and to everyone else. Of course you are free to choose what you install on your computer, but blindly advertising an AUR without knowing what are the code changes of that fork and how behind it is compared to the actual github repo is dead wrong. As a general good practice one should be always vigilant about what AUR and what codes are installed.

Did not run on Gnome Wayland, installing the following package fixed the issue sudo pacman -S xdg-desktop-portal

Please add grim as an optional dependency, as wlroots based compositors require grim to capture screenshot.

https://github.com/flameshot-org/flameshot/blob/bd2feadc65f2dc92675327244cc4f9cba5d411e5/docs/Sway%20and%20wlroots%20support.md#L5

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.