Did anyone notice that pamac is no longer getting/showing updates from the AUR? I have check multiple machines then tested with yay and no longer getting updates, on KDE I am using pamac-gtk3, on my server using xfce4 I am using pamac-gtk3 and on multiple laptops with Gnome they have pamac-gtk and none of them are getting AUR updates but in yay in the cli they are
I am not using the Pamac GUI much but for the sake of testing your question.
I have an old version of lyx (v2.3.6) installed to be able to work with the manjaro-user-guide.
I has been in the repo years ago - now it is in AUR.
So I opened the GUI - entered the preferences and enabled AUR including update check.
Then I clicked the Updates tab in the header and it shows me that lyx is available from AUR in version (2.5.0)
My answer to your question is therefore - I did not - but the issue may be real on your end - yet I have to say it again - I don’t use Pamac GUI much… making my observation of little value.
Console version is somewhat similar - the messages are normal - so are the warnings and they are harmless…
$ pamac update --aur --dry-run
Preparing...
cp: cannot access '/var/lib/pacman/sync/download-pXGpxg': Permission denied
Warning: mkosi: local (27-10) is newer than extra (26-5)
Nothing to do.
Cloning lyx build files...
Generating lyx information...
Checking lyx dependencies...
cp: cannot access '/var/lib/pacman/sync/download-pXGpxg': Permission denied
Warning: mkosi: local (27-10) is newer than extra (26-5)
Resolving dependencies...
Checking inter-conflicts...
To build (1):
lyx 2.5.1-1 (2.3.6.1-3) AUR
It looks like there might be an issue with Manjaro’s mirror cloning the AUR package list.
pamac doesn’t download the AUR database from Arch as it was hammering their servers every time Manjaro users did an update. Instead, Manjaro regularly downloads a copy to their own servers, and that is the one pamac accesses. Although that is only the package list - building a package will still download the current PKGBUILD from the AUR.
So, even if pamac shows the outdated package, building it with pamac’s GUI or via the CLI using pamac build will install the version which is actually in the AUR.
I just browsed through the AUR pages and found a random package that was updated a couple of days ago:
The AUR page says:
Package Details: fluree-bin 4.1.0-1
Last Updated: 2026-06-23 14:03 (UTC)
However, even after force refreshing my pamac databases, pamac stills shows the AUR as having fluree-bin v4.0.6-1:
❯ pamac update --force-refresh
Preparing...
==== AUTHENTICATING FOR org.manjaro.pamac.commit ====
Authentication is required to install, update, or remove packages
Authenticating as: Scott (scotty)
Password:
==== AUTHENTICATION COMPLETE ====
Synchronizing package databases...
Refreshing core.db...
Refreshing extra.db...
Refreshing core.files...
Refreshing extra.files...
Refreshing AUR...
Nothing to do.
Transaction successfully finished.
❯ pamac info fluree-bin
Name : fluree-bin
Version : 4.0.6-1
Description : Fluree — semantic graph database (CLI and embedded server)
URL : https://flur.ee
Licenses : custom:BUSL-1.1
Repository : AUR
Groups : --
Depends On : glibc gcc-libs
Optional Dependencies : --
Make Dependencies : --
Check Dependencies : --
Provides : fluree
Replaces : --
Conflicts With : fluree
Maintainer : fluree
First Submitted : Fri 01 May 2026 11:24:43
Last Modified : Fri 12 Jun 2026 23:35:33
Votes : 0
Out of Date : --
However, building it via pamac does install the up-to-date v4.1.0-1:
❯ pamac build fluree-bin
Preparing...
Checking fluree-bin dependencies...
Resolving dependencies...
Checking inter-conflicts...
To build (1):
fluree-bin 4.0.6-1 AUR
Edit build files : [e]
Apply transaction ? [e/y/N] y
Cloning fluree-bin build files...
Generating fluree-bin information...
==== AUTHENTICATING FOR org.manjaro.pamac.commit ====
Authentication is required to install, update, or remove packages
Authenticating as: Scott (scotty)
Password:
==== AUTHENTICATION COMPLETE ====
Building fluree-bin...
--BUILD MESSAGES REMOVED FOR THIS POST---
==> Leaving fakeroot environment.
==> Finished making: fluree-bin 4.1.0-1 (Thu 25 Jun 2026 16:19:50)
==> Cleaning up...
Checking keyring... [1/1]
Checking integrity... [1/1]
Loading packages files... [1/1]
Checking file conflicts... [1/1]
Checking available disk space... [1/1]
Installing fluree-bin (4.1.0-1)... [1/1]
Transaction successfully finished.
Edit: changed the example package from concord to fluree-bin
Same here, pamac shows for concord 2.2.2-1 and yay 2.2.6-1.
@linux-aarhus
even on the pamac cli it does the same thing sadly, seems like a few people are reporting back a similar issue. I hope it gets resolved.
@scotty65
Interesting that forcing a rebuild will install the latest package but doing a update no longer isn’t and will just say your up to date. Thanks for sharing.
Mod edit: Consecutive posts merged, @mentions added.
Please keep in mind that AUR is unsupported.
For security reasons - reasons that became clear mid June, 2026 - one should never blindly rebuild from custom AUR scripts.
Always validate the script beforehand… I think that came as a shocking revelation to some…
For a more reliable notification you may consider creating your own solution.
Years back I started using my own custom solution for notifying when build scripts changes.
[root tip] [HowTo] Check if your AUR build scripts have been updated
The script uses paru or yay and a local user service.
One day I will find time to create a solution which work independently of any installed AUR helper.
Please keep in mind that AUR is unsupported.
Always validate the script beforehand… I think that came as a shocking revelation to some…
Oh yeah I very much know all that especially as a long time AUR package user/maintainer but the issue isn’t with it being unsupported, it is the issue that is just recently not showing AUR package updates in pacman gtk/cli 
For a more reliable notification you may consider creating your own solution. Years back I started using my own custom solution for notifying when build scripts changes.
Sure you could but this is a project that is apart of and made by Manjaro, the issue should be resolved not ignored only to decay and get worse wouldn’t you agree?
Should I make a issue post on the Pamac Github ?
Wasn’t there something about pamac not having a maintainer right now?
Name : pamac-cli
Version : 11.7.4-2
Packager : Mark Wagie <mark@manjaro.org>
Build Date : Sa 13 Dez 2025 20:06:39 CET
What make you think that?
AUR is unsupported - in my personal opinion - Pamac as AUR helper was a mistake from the beginning.
The popularity of Manjaro and it’s own package manger, and the fact that a third party provides a custom buildscript for Pamac within AUR itself, Pamac has become AUR helper for almost any Arch Linux based distribution out there.
This popularity caused severe outages for Arch User Repository years ago and the Manjaro Community was wrongly blamed for that.
Because of these incidents the AUR webteam had to rewrite some of their handling and part of this was to provide an endpoint to fetch a complete set of metadata from AUR.
curl -o packages-meta-ext-v1.json.gz https://aur.archlinux.org
Pamac uses that metadata which it pulls from aur.manjaro.org which in turn regularly pulls the metadata from aur.archlinux.org. Thus Pamac relies on the metadata via CDN.
curl -o packages-meta-ext-v1.json.gz https://aur.manjaro.org
How often or when the CDN at aur.manjaro.org refreshes the data from Arch Linux I have no idea.
I did an experiment and as expected I have small difference between the upstream version and the cdn version
09:25:55 â—‹ [fh@tiger] ~/test
$ curl -o aur-arch.json.gz https://aur.archlinux.org/packages-meta-ext-v1.json.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 12.91M 100 12.91M 0 0 22.91M 0 0
09:26:01 â—‹ [fh@tiger] ~/test
$ curl -o aur-mjro.json.gz https://aur.manjaro.org/packages-meta-ext-v1.json.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 12.87M 100 12.87M 0 0 52.19M 0 0
09:26:20 â—‹ [fh@tiger] ~/test
$ ls -l
total 26420
-rw-r--r-- 1 fh fh 13547619 25 jun 09:26 aur-arch.json.gz
-rw-r--r-- 1 fh fh 13502897 25 jun 09:26 aur-mjro.json.gz
If you feel it is that important - sure, do that - but you should search the existing issues to make sure it has not already been reported.
EDIT 2026-06-24T22:00:00Z
Judging from my experiment the issue may not be the pamac aur plugin, but could the CDN.
I extracted some test data - using the fluree-bin package mentioned earlier.
The upstream version contains
{
"ID": 2135399,
"Name": "fluree-bin",
"PackageBaseID": 235228,
"PackageBase": "fluree-bin",
"Version": "4.1.0-1",
"Description": "Fluree — semantic graph database (CLI and embedded server)",
"URL": "https://flur.ee",
"NumVotes": 0,
"Popularity": 0.0,
"OutOfDate": null,
"Maintainer": "fluree",
"Submitter": "fluree",
"FirstSubmitted": 1777598683,
"LastModified": 1782223417,
"URLPath": "/cgit/aur.git/snapshot/fluree-bin.tar.gz",
"Depends":
[
"glibc",
"gcc-libs"
],
"Conflicts":
[
"fluree"
],
"Provides":
[
"fluree"
],
"License":
[
"custom:BUSL-1.1"
]
}
The CDN version contains
{
"ID": 2119873,
"Name": "fluree-bin",
"PackageBaseID": 235228,
"PackageBase": "fluree-bin",
"Version": "4.0.6-1",
"Description": "Fluree — semantic graph database (CLI and embedded server)",
"URL": "https://flur.ee",
"NumVotes": 0,
"Popularity": 0.0,
"OutOfDate": null,
"Maintainer": "fluree",
"Submitter": "fluree",
"FirstSubmitted": 1777598683,
"LastModified": 1781271333,
"URLPath": "/cgit/aur.git/snapshot/fluree-bin.tar.gz",
"Depends":
[
"glibc",
"gcc-libs"
],
"Conflicts":
[
"fluree"
],
"Provides":
[
"fluree"
],
"License":
[
"custom:BUSL-1.1"
]
}
Pamac can only provide the data as they exist on the CDN. If the CDN version is older than upstream - the issue lies elsewhere - namely at the CDN.
Thanks, but I know that—it’s right there in my post.
I don’t think it was a mistake and has been what made Manjaro so amazing with the graphical package manager merging repo/AUR and FLatpak to be managed through pamac which is great for new users who just uses repo/flatpak packages for example.
Mistakes were made with the package manager but it was in the end resolved to make it better
Ahh I see that’s interesting to know!
Okay I’ll check to make sure there isn’t any duplicates and make a issue report there 
Please see my edit above
I think it is the CDN which may be the issue.
$ drill aur.manjaro.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 31666
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; aur.manjaro.org. IN A
;; ANSWER SECTION:
aur.manjaro.org. 15 IN CNAME 1435236112.rsc.cdn77.org.
1435236112.rsc.cdn77.org. 15 IN A 121.127.45.82
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 45 msec
;; SERVER: 172.30.30.1
;; WHEN: Thu Jun 25 10:05:44 2026
;; MSG SIZE rcvd: 126
I remembered that, and it does kind of sound like the maintainer is no longer active:
From what I remember, there’s a maximum of 10 minutes between the AUR database and its API. And perhaps the same between the AUR database and Manjaro ??
not fixed.
# default used by yay
curl -s https://aur.archlinux.org/rpc/v5/search?arg[]=fluree-bin
{"resultcount":1,"results":[{"Description":"Fluree — semantic graph database (CLI and embedded server)","FirstSubmitted":1777598683,"ID":2135399,"LastModified":1782223417,"Maintainer":"fluree","Name":"fluree-bin","NumVotes":0,"OutOfDate":null,"PackageBase":"fluree-bin","PackageBaseID":235228,"Popularity":0,"URL":"https://flur.ee","URLPath":"/cgit/aur.git/snapshot/fluree-bin.tar.gz","Version":"4.1.0-1"}],"type":"search","version":5}
# option for yay ("rpc": false,)
curl -s https://aur.archlinux.org/packages-meta-ext-v1.json.gz | zcat | grep 'fluree-bin'
{"ID":2135399,"Name":"fluree-bin","PackageBaseID":235228,"PackageBase":"fluree-bin","Version":"4.1.0-1","Description":"Fluree — semantic graph database (CLI and embedded server)","URL":"https://flur.ee","NumVotes":0,"Popularity":0.0,"OutOfDate":null,"Maintainer":"fluree","Submitter":"fluree","FirstSubmitted":1777598683,"LastModified":1782223417,"URLPath":"/cgit/aur.git/snapshot/fluree-bin.tar.gz","Depends":["glibc","gcc-libs"],"Conflicts":["fluree"],"Provides":["fluree"],"License":["custom:BUSL-1.1"]},
# used by pamac
curl -s https://aur.manjaro.org/packages-meta-ext-v1.json.gz | zcat | grep 'fluree-bin'
{"ID":2119873,"Name":"fluree-bin","PackageBaseID":235228,"PackageBase":"fluree-bin","Version":"4.0.6-1","Description":"Fluree — semantic graph
database (CLI and embedded server)","URL":"https://flur.ee","NumVotes":0,"Popularity":0.0,"OutOfDate":null,"Maintainer":"fluree","Submitter":
"fluree","FirstSubmitted":1777598683,"LastModified":1781271333,"URLPath":"/cgit/aur.git/snapshot/fluree-bin.tar.gz","Depends":["glibc","gcc-li
bs"],"Conflicts":["fluree"],"Provides":["fluree"],"License":["custom:BUSL-1.1"]},
yes, cdn error since 10 days ? 15Juin 
curl -I https://aur.manjaro.org/packages-meta-ext-v1.json.gz
...
last-modified: Mon, 15 Jun 2026 03:24:03 GMT
curl -sI https://aur.archlinux.org/packages-meta-ext-v1.json.gz | grep ^date
date: Thu, 25 Jun 2026 08:28:57 GMT
Looking at the metadata for the relevant endpoints, it looks like an Manjaro maintained bucket at Amazon.
One can only speculate why it has not been updated.
Summary
10:05:44 â—‹ [fh@tiger] ~
$ curl -I https://aur.manjaro.org/packages-meta-ext-v1.json.gz
HTTP/2 200
date: Thu, 25 Jun 2026 08:28:12 GMT
content-type: application/gzip
content-length: 13502897
last-modified: Mon, 15 Jun 2026 03:24:03 GMT
x-rgw-object-type: Normal
etag: "2e4f56fde3cb277739f614bd4966c310"
x-amz-meta-s3cmd-attrs: atime:1781493842/ctime:1781493842/gid:0/gname:root/md5:2e4f56fde3cb277739f614bd4966c310/mode:33188/mtime:1781493628/uid:0/uname:root
x-amz-storage-class: STANDARD
x-amz-request-id: tx00000598382f12c06d0b9-006a3ce61d-c807316-prg
x-77-nzt: lGWifF1WdHmBomkCVhtsY3v89qW8GZtg4LI84ICn5NM5OYbb9Ui8fvMsq5VwYKruTO9KWQOmkWkkg6+Fuw
x-77-nzt-ray: c1fb98194c8163e49ce63c6a8a68d933
x-77-cache: HIT
x-77-age: 51
server: CDN77-Turbo
x-77-pop: copenhagenDK
accept-ranges: bytes
10:28:12 â—‹ [fh@tiger] ~
$ curl -I https://aur.archlinux.org/packages-meta-ext-v1.json.gz
HTTP/2 200
server: nginx
date: Thu, 25 Jun 2026 08:28:21 GMT
content-type: application/gzip
content-length: 13547702
accept-ranges: bytes
cache-control: max-age=300
etag: "6a3ce578-ceb8b6"
expires: Thu, 25 Jun 2026 08:33:21 GMT
last-modified: Thu, 25 Jun 2026 08:23:20 GMT
strict-transport-security: max-age=31536000; includeSubdomains; preload
just speculation
It is possible that the AUR webteam took the metadta endpoint offline to prevent the endpoint from spreading the git repositories of the malware from the metadata.
If that is so - then the Manjaro service providing updates to the bucket may lack proper error handling and that has caused the service to fail and it will only resume when the service has been restarted.
I guess this explains why there wasn’t a notification of nordvpn-gui-bin to 5.1.0-1 on June 15th.
While waiting for someone to restart the service pulling the aur metadata you can help yourself with this little snippet
The snippet uses curl to fetch the file from aur.archlinux.org and writes it to the location where pamac reads it from
sudo curl -o /var/lib/pacman/sync/packages-meta-ext-v1.json.gz https://aur.archlinux.org/packages-meta-ext-v1.json.gz
Another option - not recommended - is to mangle the file /etc/os-release change the ID=manjaro to something else.
This will also impact all other tools which reads the specific file.
EDIT:
pamac is likely to overwrite the file if/when it is run with the option --force-refresh
It’s a plague or disease kind’a situation - you will have to decide which one like the least
This is interesting and got me thinking about this in relation to the recent issues in AUR. Also I may have misunderstood how this all works but Pamac users should be aware of this as it could in theory result in malicious package build files being missed; particularly in the recent case where commits were being revoked in the AUR but presumably the manjaro copy would still include the malicious build files until the server syncs the CDN. Of course this also means in some cases pamac users could be protected for a small amount of time at the other end of the process before the CDN is synced.
Package build files should therefore be checked on device after they’ve been downloaded as part of the installation or upgrade and not rely on the AUR website to check them?
I recall that being mentioned recently in another topic – it was in reference to pamac-manager – the “GUI” frontend for pamac that most obliviously just call “Pamac”.
The GUI has a troublesome history, and as far as I understand has had only one developer who is not very active in it’s development anymore. Again, this is my understanding, and any correction or further clarification will doubtless be welcome.
This is the most direct response to your question that I can offer, at this time.
It has always been recommended to check the PKGBUILD before installing software via the AUR. The pamac CLI provides inline options to do this – whether they are actually used or not by AUR users, is another story completely.
The options are there, and we greatly encourage people to use them; alas, the adage rings true “You can lead a horse to water…”.
I understand that pamac-manager (Add/Remove Software) also provides a way to check a PKGBUILD, however, as I typically don’t use the GUI, I’m unable to vouch for it’s effectiveness.