Comments: Mitigate and prevent GPGME error when syncing your system


What is that means? Can’t understand how some entity of SublimeHq (in this example) can affect whole database signed or not signed result.

There are repos/databases with package descriptions.
There are single packages.
And there is some unclassified “SublimeHq” entity.

If it is a “container package” (which provides text and merge apps), then I can’t find any packages output with pacman -Ss ublime in Manjaro repos.

What means that “entity” term? Could it be projected onto Manjaro infrastructure terms? How to name the object more descriptive?

While the end-user tutorial fixes the issues users met ([Unstable Update] 2021-11-24 - ICU 70.1 rebuilds, VirtualBox 6.1.30 - #15 by garvitjoshi9), why to leave the fixes as each user action to be done and not to fix the Manjaro infrastructure/environment once and for all?

Possible fixes are:

  1. to make mirrors to function as mirrors, not as selfies with unique less predictable behavior. For example, I have the SigLevel = Required DatabaseOptional config and I never met the issue with pamac or pacman. So not all servers involved into the issue, therefore this variant is to fix servers configs to make them actual mirros, not as unique, but to be a part of infrastructure service.


  1. to fix pacman.conf file for all users at once.

I do not know how hard to implement possible solution (1), but (2) requires to fix that one single aspect (to SigLevel = Required DatabaseNever) in config file, so every user will get the changes: with new OS copy installations or via .pacnew config file to resolve.

May be any of (1) or (2) can collapse this tutorial as a way more useless (it is good to have no issues, right?) in most cases (as users generally never meet the issue afterwards) to make Manjaro OS be more automated in use: no further issues on that and centralized fix - for all users at once?


some repo have “repo”.sig :wink: (example, 2)

solution (1) : if you want less security … (not for me)

here, we have this error only if config mirror is bad. is write in first message: some (bad) mirrors return html page for 404 error (404 == file not found)

Patrick, yes, you provide example of repository signature, but the question about relation: hot some unclassified entity of SublimeHq result the whole repo to have (or have no) repo signature.

Hooray! That’s the point! So solution (1) as possible fix: we need mirror to be a mirror, not some unique unpredictable server which just looks like server of Manjaro infrastructure, but actually has “it’s own life” (settings/configs/services).

You are missing the point which creates the issue. There is no bad mirror configuration in play. If a sysadmin has decided to return a more human error page - instead of the boring webserver defaults - theres no argument against it.

First: The default config - uses DatabaseOptional - no problem.
Second: All mirrors are delivered through a webserver - the most popular being Apache and Nginx.

When a system connects to the said webserver in an automated manner which will be the case of a mirror service - it is always the system consuming the service which must validate the received data.

As @papajoke pointed out is what I described albeit using other words.

The consumer cannot make demands to the providing service but needs to validate if the received data is valid for the intended purpose and act accordingly.

In this case the consumer of the mirror provided data needs to tell the script/application - do not use the signature files because they are plain text error messages.

1 Like

not exactly, almost all mirrors return a html page :

$(pacman-conf -r core | awk -F' ' '/^Server/ {print "curl -sIL "$3"/core.db.sig"}') | grep -E 'HTTP|content'

We have this error if mirror send html page (404 not found) and not 404 code in HTTP header
EDIT: I made a script to test them all, they all return 404 in HTTP

So if no problem, then

is not needed, right?

The name of it is inconsistency. They are not mirrors, they are selfies with their responds they like.

If the predictable, exact behavior is not the purpose of the inftrastructure, then it is ok, please ignore my posts, let end-users will be glad to add meet issues, to search solutions, to add patches in their end for each users who meet the issue: that’s the tutorial article purpose to shift issue fixes to each of end users who suddenly met the issue. To chose mitigation instead of actual fixing the cause of issue.

Is it possible not to install the packages but only download then and check signatures manually?

Eugen, please expand details of the idea

Hm, generally installation process goes like this:

  1. Verifying file integrity.
  2. Verifying file signatures (trusted or not).
  3. Unpacking (packages are archives), and since last level became zst, they are double level archive with tar archive inside.
  4. Pre-copying hooks.
  5. Copying files, may be setting file/folder attributes.
  6. Post-copying hooks.

Please expand details of idea on how whole the process could looks like.

Also can’t figure out how package signatures related to databases signatures presence or absence (which I suppose is the root cause to make users to change their configs to interact with some servers).

Any and all mirrors are provided by volunteers - free of charge. The only expectation the mirror provider must meet is

  • stability
  • rsync the complete repo 120G

The tutorial is intended to explain why such issue can surface and how to deal with it.

No - that is not correct - you are still not getting the point and frankly - your attitude towards the solution is the consumer-I-bought-a-product-my-issue-your-responsibility-fix-it attitude.

You should know by now that Linux != Windows and you cannot make demands like that.

Manjaro is based on Arch and just like Arch - all activities - with no exceptions - are provided by volunteers and the contribution takes many different forms e.g. (not covering all type of contributions). Even though more than one business entity based on knowledge and expertise related to Manjaro exist, Manjaro is still entirely based on a joint volunteer effort - and Manjaro wouldn’t exist otherwise.

The business entities does not make Manjaro a consumer product - the entities wouldn’t exist if there were no Manjaro. (

  • donations
    • mirror space on an existing web server
    • mirror space on dedicated servers
    • cloud hosted dedicated mirrors
    • cdn ( is contributing a global mirror network)
    • money
    • wiki articles
    • forum tutorials
  • coding skills
  • time - lots of time - free time - spare time

The package manager has the specific setting for at reason so the end user is able to adjust settings.

If Manjaro changed this specific settings to accomodate for the a theoretical situation where the response received is not a signature - the reaction would be completely different - you imagine.

This has become a theoretical discussion - offtopic - for the original topics intention - so I am moving it to a separate topic.

The method to install sublime-text and sublime-merge is to add their keyring to pacman trusted database and the official Sublime HQ repo to pacman.

Server =

When you sync with pacman -Syy you will find signature files for the database.

Other than that package repo I am not aware of any repo signing the databases.

Thank you for your answers.

As I understand, the issue origin has nothing to do with Manjaro servers: if assumption (1) below is right, then we adds external repo and have new db file from Manjaro-unrelated source.

  1. So the issue comes only after we added Sublime’s text or merge apps repos into ours /etc/pacman.conf you qouted [sublime-text] \n Server = ... and that produces brand new db of sublime-text.db file, right?

  2. OK, and alongside with other unsigned databases produces the situation of issue, and your tutorial article tells how to fix that issue, right?

  1. If both assumptions (1) and (2) above are correct, then according to your main article quoted in

    The setting in pacman.conf instructs pacman to look for optional database signature files. Neither
    Archlinux nor Manjaro signs the database - only the packages.

    Manjaro do not signs their databases, so it is pointless to use the
    SigLevel = Required DatabaseOptional
    and we can prevent any future possible issues with database signatures checking for additional non-Manjaro repos by
    SigLevel = Required DatabaseNever

    Cause Manjaro already not does not db signatures that’s why even cleanest initial state of pacman.conf with the SigLevel = Required DatabaseNever will be safe to use, right?

  2. If (3) is right, then why not to change DatabaseOptional to DatabaseNever by default as it is not affects Manjaro repos and in the same time prevents future possible problems with other repos?
    Re-worded (4): what the reason to have default DatabaseOptional if not to use database signatures at all?
    Re-phrased again as assumption: The DatabaseNever could prevent future possible problems of adding new non-Manajro repos and does not affects Manjaro databases usage (they are already do not use db signatures), so we need to change to DatabaseNever by default in pacman.conf for all Manjaro users.

Please note, that may be I am so stupid that I can’t understand the issue origin and possible fix methods even after your several clarifications. So just close the thread to prevent further time wasting.

  1. I will proceed with partially off-topic: other, less comprehensive way to install Sublime’s apps:
$ pamac search sublime -q

Why not to use AUR and to chose a bit harder ways? What could be a possible benefits of adding of sublime-text repo into pacman.conf?

Because it’s the official way to install Sublime for Arch.

That’s like asking, what are the benefits of installing official Manjaro packages from the Manjaro repositories?

Xyne & TeeJeeTech do.

1 Like

Got it. Official / recommended way. Thanks!
But that closes only semi-off-topic (5) item.

The (4) question remains. The (1, 2, 3) assumptions are only stairs to the (4).



Yes - but it well not be default. I am certain you are aware that all kinds of stories are spread about Manjaro - if the default was changed to accomodate your wish - it would just add another item to the FUD machine.

Because it allows for future signing of databases - without requiring several 100000s of users to change their pacman.conf - should it become important.

Answered by @Yochanan - it is the official way to keep up-to-date with 2 outstanding developoer applications (I have been a licensend user of Sublime Text predating my Manjaro usage) and supporting Sublime Merge was a nobrainer - it is better than any git gui I have previously used.

I have a very clear understanding of how and why this issue comes up from time to time as I have been troubleshooting the issue when I was a mirror provider. The troubleshooting process is documented in the following issue I created when investigating.