Pamac no longer getting updates from AUR (server problem)

Good thinking, @bananamangodog.
I never thought of this in the light of the recent events since i do not use pamac for aur.
Although if that database is pulled several times a day it would not matter much.

Yes, it is a separate tab before one starts the build.

No it won’t.

It would contain link to build build files - which would become invalid during incident damage control - not the files themselves.

The sample data provided in comment #10 show exactly what the content the metadata provides about a given custom build script.

This is a good workaround until aur.manjaro.org can be updated

$ pamac info ventoy-bin
Name                  : ventoy-bin
Version               : 1.1.16-1
 
Last Modified         : Thu 25 Jun 2026 15:03:17 BST

Malicious AUR packages were easier to identify in pamac because it showed the Last Modified date that was not visible in yay at the time

Absolutely, but I know a lot of people mistakenly check build files via the web interface prior to installing packages from AUR because they’ve been told to check and the other tools provided are too difficult for them to use for a myriad of reasons. Sometimes you need to give the horse a bucket, not a straw.

Small risk doesn’t equate to safe - and if the update was stopped like it appears may have been the case does that widen the risk or reduce it? (I don’t know enough about how it all works, I’m just hypothesising from what little I do know).

I see, I was under the wrong impression of exactly what was synced. I’ve downloaded the packages-meta-ext-v1.json.gz file and had a look myself and see what’s going on. Thanks.

I haven’t used yay for many years but I was always impressed by the amount of info it did show. I am surprised to learn it didn’t/doesn’t show the last modified date. However (if I’m now understanding correctly), the last modified date is obtained from the metadata package. Pamac uses the CDN copy and therefore may provide different information to what is actually on AUR. Which misleads the user into thinking the package is ok, but if the package was modified after the last metadata sync you could install a package you think is ok but actually had been modified between the sync and the install.

I have never used yay and was not aware that it did not show the last modified date until it was included in a recent update

yay v13 and the AURpocalypse | Keys and Craft

Display PKGBUILD Last Modification Time

yay will now display how long since the last modification of the PKGBUILD occured. A package which has been recently modified is not a reason to avoid it, but it is a reason to be more careful and review the PKGBUILD before installing. Likewise, a package that has not been modified in a long time is not a reason to trust it, but it is a reason to be more confident that it has been reviewed by the community

Pamac is working normally, but Manjaro AUR mirror aur.manjaro.org has not been updated since 15 Jun 2026

AUR package updates no longer showing up in Pamac · Issue #577 · manjaro/pamac · GitHub"]

Workaround for this is to update AUR database from aur.achlinux.org

sudo curl -o /var/lib/pacman/sync/packages-meta-ext-v1.json.gz https://aur.archlinux.org/packages-meta-ext-v1.json.gz

Or check aur.archlinux.org documentation, download package and install locally

Should be fixed now:

curl -I https://aur.manjaro.org/packages-meta-ext-v1.json.gz
HTTP/2 200 
date: Fri, 26 Jun 2026 06:18:09 GMT
content-type: application/gzip
content-length: 13553385
last-modified: Fri, 26 Jun 2026 06:17:02 GMT
x-rgw-object-type: Normal
etag: "558e416395c4879062197788e2313667"
x-amz-meta-s3cmd-attrs: atime:1782454519/ctime:1782454517/gid:0/gname:root/md5:558e416395c4879062197788e2313667/mode:33188/mtime:1782454479/uid:0/uname:root
x-amz-storage-class: STANDARD
x-amz-request-id: tx0000066c74fab33633a18-006a3e198e-c807316-prg
x-77-nzt: k4u3nKkJv68s7JVnDLzqbyBKSP9xYOCMbty2SLkHGCRxsjYAG/oKyg3ULzuXCLoucg
x-77-nzt-ray: 1cb09c0eda306f25a1193e6ae57f1e30
x-77-cache: HIT
x-77-age: 16
server: CDN77-Turbo
x-77-pop: frankfurtDE
accept-ranges: bytes