I want to use pamac

Support AUR
9

Probably not going to happen. I don’t want to be hard on you, or say things that might frustrate you, but it really ISN’T Manjaro’s FAULT. In fact, it has nothing to do with Manjaro.

See, the AUR is Arch (Linux) User Repository. Not Manjaro User Repository. Also, the packages you find in the AUR isn’t created by the Manjaro, or even Arch Linux official team members, but by the U sers. Yeah, sure, there are packages there that’s maintained by some of the Manjaro team members, but it’s not official, otherwise it wopuld probably have been in the repositories.

That mirror has been decommissioned AFAIK.

It won’t. Because the AUR isn’t a Manjaro or even Arch Linux server. It’s jusst a repository of recipes, to put it like that. And those packages, those ingredients, are downloaded from all over the internet.

Some other server(s) might also be decommissioned or even just changed a bit, so that It looks like the machine is gone, to pamac. So the global refresh probably did that for you and that’s why the official repositories are now working.

Try removing that file locally, to force a download of a newer one:

sudo rm /var/tmp/pamac-build-<username>/packages-meta-ext-v1.json.gz

Where <username> is the name of your actual user on the PC.

1 Like
10

This is the answer I have seen so many times and I simply don’t accept that.
Reason: If there was zero way of getting that file by any other means, then yes, I would agree. But since I CAN access and download the file through other means, this IS a pamac issue. Be it they need to change the METHOD they access the file because the way they rely on is through others doesn’t work, but no matter, it’s pamac.

It exists on https://repo.manjaro.org/ and:

pacman-mirrors                                                                                                                                                                                     4 ✘ 
Pacman-mirrors version 4.23.2
Local mirror status for stable branch
Mirror #1   --  00:55   Sweden   https://mirror.zetup.net/manjaro/
Mirror #2   --  01:05   Sweden   https://ftpmirror1.infania.net/mirror/manjaro/
Mirror #3   --  02:35   Sweden   https://ftp.lysator.liu.se/pub/manjaro/
Mirror #4   --  02:34   Norway   http://mirror.terrahost.no/linux/manjaro/
Mirror #5   --  01:23   Denmark  https://mirrors.dotsrc.org/manjaro/
Mirror #6   OK  00:16   Finland  https://manjaro.kyberorg.fi/

So I think it’s all good on that front.

Did that, nothing changed. Besides, It’s the server, not the file the error references to.

Again, I completely understand that pacman DO NOT HAVE ANYTHING TO DO WITH AUR, all I am saying is: Errors with using pamac upgrade -a in almost ALL OCCASIONS happens directly after I have interacted with pacman-mirrors. I see a CLEAR correlation between them but I have no idea why. The error usually fixes itself within 24h so I have learned to live with it, this time, it has gone way beyond that time.
This is my experience, I can not speak for others.

Edit

Wait, maybe I have misunderstood something here. Is pamac not supported/created by manjaro?
Is aur.manjaro.org not owned by manjaro but rather community driven somehow?
If so, I start to understand the complexity and what you mean.
But if they ARE maintained by manjaro, yepp, this is a manjaro issue in my eyes, as a manjaro user.
AUR itself is obv not controlled by manjaro.

1 Like
11

This AUR file is maintained by Manjaro and necessary to use the AUR with pamac. But it is distributed by a CDN which is unwilling to fix this issue.
You can only wait.

Or disable the AUR in pamac and use another AUR helper (like paru).

1 Like
12

How are they responsible for how aur.manjaro.org handles certificates? I have to ask because as a noob, it makes zero sense to me, unless they ALSO control the whole server?

This is my exact point, how is it that the official package manager can not what others can, but at the same time “not at fault”?

13

I stopped using pamac except to see what updates are out the. In manjaro for overall updates I use topgrade. for individual apps pacseek with pikaur under the hood for my AUR helper.

1 Like
14

Look, I’m going to step away from the technical part a second and look at it from another perspective. Not everything is going to be fun, but the most valuable critique often are like that.

I approach this as a custmore, because that is kinda what I am to manjaro, they don’t REQUIRE money from me but they don’t shy from asking for it, and I have ZERO problems with that, I appreciate them reminding the community that they are driven by community money.

If you have donated or not should not matter, even “free” users contribute value by simply being users and talking about that to others. That is the best pr you could possibly have, FOR FREE (kinda).
I happen to be a contributor, I fkn hate saying that, because again, THAT SHOULD NOT MATTER. I even went to lengths to keep it anonymous, but here we are, if this can change ANYTHING about this, screw it.

But here is the catch. If I use manjaro, and if manjaro use aur as a promotion for their product, I expect that to work, especially if there is a tool within manjaro that I can change a setting to activate support for aur in the gui!

Look at it this way. I get a car. the car stops working sporadically after I fill it with gas. I contact my seller and they inform me “yeah, we are aware, just wait a little while and it fixes itself, we have no control over the software doing this”.

Sounds insane right?

The analogy is not exact ofc, I see and understand the difference of open source and an actual complete holder, but the mentality of “this is not our fault” is VERY strange here.

I also understand that there are limits to what manjaro can do and have focus on, but this particular issue has existed for a VERY long time. There are post a few years back referencing this.

1 Like
15

Have look at his thread: Pamac fails to synchronise due unacceptable TLS certificate

LetsEncrypt uses SHA1 for performance reason and llibsoup3 has problems with it, which is used in pamac. Guess that is the summary of the whole story.

To add here: I get also sometimes that error, but I disabled auto-updating of AUR packages and do it on demand. When I request it the AUR DB too often, I get again the same error.

16

I guess I have to look into something like that, but it SUX tbh. As I stated in the title “I want to use pamac” for the simple reasons: that is what is promoted as “their package manager”, because that is what I have been using since I started using manjaro (and it mostly works) and because the first response (from a manjaro team meber might I add) to my absolute first post in this forum was: "welcome to manjaro, to to install from the AUR use manjaros build in package manager pamac by typing pamac build it87-dkms-git (after me trying to use my debian knowledge to clone from aur).

17

I make a little script for test libsoup package (v3 or v2) …

#!/usr/bin/env python
import sys
import gi

version = '3.0'
if len(sys.argv) > 1 :
    version = sys.argv[1]
if version != '2.4':
    version = '3.0'

gi.require_version('Soup', version)
from gi.repository import Soup
from gi.repository import GLib


URL = 'https://aur.archlinux.org/packages-meta-ext-v1.json.gz'
URL = 'https://aur.manjaro.org/packages-meta-ext-v1.json.gz'

print("libsoup", version, URL)

session = Soup.Session()
if version == '2.4':
    uri = Soup.URI.new(URL)
    request = session.request_http_uri('HEAD', uri)
    try:
        request = request.send(cancellable=None)
    except gi.repository.GLib.GError as err:
        print(err)
if version == '3.0':
    uri = GLib.Uri.parse(URL, GLib.UriFlags(Soup.HTTP_URI_FLAGS))
    message = Soup.Message.new_from_uri("HEAD", uri)
    request = session.send(message)

print("ok")

for me, only works a few times (7/10)… (if ok, return nothing)

python script.py

   > gi.repository.GLib.GError: g-tls-error-quark: Unacceptable TLS certificate (2)

:thinking:

3 Likes
18 
python ./script.py                                                                                                                                                                                   ✔ 
Traceback (most recent call last):
  File "/home/bedna/./script.py", line 11, in <module>
    stream = request.send(cancellable=None)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gi.repository.GLib.GError: g-tls-error-quark: Unacceptable TLS certificate (2)

Not exactly sure what I’m looking at though. xD

Edit, wait, you are correct, sometimes I get no errors when running it.

19

@papajoke you fixed it, SOMEHOW!

I kept running that script a few times, then after like 5-6 tries, it returned nothing, so I ran it again, that brought back the errors, until they once again didn’t BUT THIS TIME, I ran pamac upgrade -a AND IT WORKED!!!

Now, WHY did this happen, I would love to understand!

python script.py                                                                                                                                                                                  
Traceback (most recent call last):
  File "/home/bedna/script.py", line 11, in <module>
    stream = request.send(cancellable=None)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gi.repository.GLib.GError: g-tls-error-quark: Unacceptable TLS certificate (2)

python script.py                                                                                                                                                                                  
Traceback (most recent call last):
  File "/home/bedna/script.py", line 11, in <module>
    stream = request.send(cancellable=None)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gi.repository.GLib.GError: g-tls-error-quark: Unacceptable TLS certificate (2)

python script.py #no errors 

python ./script.py #no errors

pamac upgrade -a                                                                                                                                                                                    
Preparing...
Synchronizing package databases...
Refreshing community.db...                                                                                                                                                                                          
Refreshing AUR...                                                                                                                                                                                                   
Nothing to do.                                                                                                                                                                                                      
Transaction successfully finished.
20

for me:

gnutls-cli --tofu aur.manjaro.org                                                                                                                
 ...
- Status: The certificate is trusted. 
Host aur.manjaro.org (https) has never been contacted before.
Its certificate is valid for aur.manjaro.org.

curl -Iv 'https://aur.manjaro.org/packages-meta-ext-v1.json.gz' 
...
* Server certificate:
*  subject: CN=1715854792.rsc.cdn77.org
*  start date: Apr 27 17:10:39 2023 GMT
*  expire date: Jul 26 17:10:38 2023 GMT
*  subjectAltName: host "aur.manjaro.org" matched cert's "aur.manjaro.org"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.

My script return error (only) sometime , the same error as you, 3 times out of 10

So, is a random libsoup bug :sob:

21

Can I use this in the future you think, like, if it happens again, I keep running this script and when it returns no errors, I run pamac upgrade -a? :open_mouth:

22

this script make noting :rofl: only test if certificate is valid for libsoup !
Sometimes for you (and me) , it’s valid

23

Yeah, I ran that in my initial post, now I’m scared to run it again, what if I break pamac+aur again. xD

But even though I am glad it works now, this HAS to be addressed and fixed somehow.

24

Theres nothing being broken or fixed.
Its simply checking whether it works at the given moment.
So far it appears there is some sort of bug making libsoup/cert unreliable.

Of course for people using the AUR manually or with any other helper (paru, etc) this is a non-issue.

25

No, that’s out of your reach, it’s on the server side. Just my findings about possible reasons for the problem after I checked various domains using let’s encrypt certificates.

In detail this seems to be let’s encrypt specific as in how the certs configured to ensure revocation checks. There are various problems with the revocation handling and various workarounds with their specific other problems. The current effect seems to be caused by this. I don’t think that this can be fixed on then client side at all.

1 Like
26

I think that is the effect of load balancing.

27

yes, because after modifying the script, same random error on the HEAD with libsoup 3 and 2.4
and no error with aur.archlinux

28

Install Topgrade and do topgrade --dry-run to see what updates there are before running the topgrade command.