Manjaro and Arch repository with privacy oriented software

[as400]

Repo updated:

New versions:

1. Matrix Mirage (matrix-mirage-git-r2286.60a57db3-1-aarch64)

New additions:

1. Vorta (vorta-0.7.1-2-any) - Vorta is a backup client for macOS and Linux desktops. It integrates the mighty BorgBackup with your desktop environment to protect your data from disk failure, ransomware and theft.

[as365n4]

@as400 and @llsf

Whilst everyone appreciates your efforts in creating this repo, would it not be better to push your stuff upstream so that it becomes part of the official repos or at least part of AUR. And some packages you "provide" are coming from AUR in the first place it seems if one reads your https://gitlab.com/ohfp/pinebookpro-things .

From my personal view adding a random repo from some "strangers" of the internet is a big no no, especially when it is "privacy" labeled .

[llsf]

You do have a point, to some extent. There are a few reasons why the current approach still makes sense, at least in my opinion:

Some of the packages are "just" taken from the AUR. For those packages, the repo serves as a "convenience" – you just don't have to build the packages yourself.

In most cases, though, PKGBUILDS need to be slightly (or heavily) modified to be buildable on aarch64. That's what we do with this repo.

Also, some packages take a looong time to build, so we're offering the choice for people to build things themselves or to just pick a binary.

Your main point is still moot, imho, as we absolutely point out where PKGBUILDs are coming from, where our modifications can be viewed and thus used to build things yourself, should you not want to put trust into a random repo (which is very understandable). And we actually _do_ try to get things upstreamed, where feasible – bitwarden and riot had once been part of the repo and aren't anymore; jitsi-meet and librewolf are actually maintained by us/me in the AUR as well; the ferdi-AUR-maintainer got a PR etc.
Sometimes, upstream or AUR maintainers are not interested in aarch64, and in some cases (like with signal) upstreaming would be a _huge_ effort, for which there currently is not enough time available.
And sometimes the current solutions to build things are just somewhat hacky or not super-clean, and not necessarily in a state where upstreaming or submission to the AUR would be reasonable.

So to sum it up: feel free to use the repo, or to ignore the repo and just grab the PKGBUILDs to build things yourself – we encourage that! That's why you have a choice.

If you want things to get upstreamed sooner: Things are open and available – why not just do the work yourself? :)

Until then, we'll just keep maintaining things, while giving people the choice to trust us with binaries – or to just go to the source and use the resources there to build things on their own, without having to figure out on their own how to get things built on aarch64 in those cases where it's more complicated.

[as400]

Actually there is nothing more to add from me. Except one thing.

When you grab a distro and install it - you do the same thing. It's just binaries from some random internet folks.
And of course we are the same - random internet folks. So if we follow this path...

[as365n4]

My sincere apologies if I have stepped onto someone's toes, it was not my intention.

Personally I build either from AUR or Source myself and if it requires modifying the PKGBUILDS then so be it.

But in general if the Provider of a Service or App is not providing a ready-build package or source then I rather be not their "customer" and use something else or if no alternative is available, then I can live without it very well, tbh.

And it is and was not my intention to discredit your endeavour or your intentions as you seem to put a lot of effort into your project to provide others with ready made packages.
I only felt that it is duplication of work, which seems wasted energy to me since there is a structure in place already (AUR).
Plus there is still the trust issue, which for me is still a no no.

And there is a difference between a random repo found on the Internet and a mainline Arch or Debian repo as one can not directly upload a package without being a Maintainer or Developer in the first place or have to know a Sponsor which can upload for one.

[as400]

No offence taken

You have a point. I understand it.

[e-v]

And there is a difference between a random repo found on the Internet and a mainline Arch or Debian repo as one can not directly upload a package without being a Maintainer or Developer in the first place or have to know a Sponsor which can upload for one.

Except absolutely anyone can upload anything to the AUR. The process does not require any form of approval, assessment or supervision. I've seen a lot of very badly written PKGBUILDs there.

This is somewhat mitigated by the fact that comments for each PKGBUILD in the AUR are centralised and public, but this is hardly a strong protection.

[llsf]

@as365n4: no toes were stepped on, no worries ^^

--

Just a quick note: I've managed to build ferdi again with some slight modifications to get it to work with electron 10; so if anyone is still using it, things should be fine again now :)

[as365n4]

And there is a difference between a random repo found on the Internet and a mainline Arch or Debian repo as one can not directly upload a package without being a Maintainer or Developer in the first place or have to know a Sponsor which can upload for one.

Except absolutely anyone can upload anything to the AUR. The process does not require any form of approval, assessment or supervision. I've seen a lot of very badly written PKGBUILDs there.

This is somewhat mitigated by the fact that comments for each PKGBUILD in the AUR are centralised and public, but this is hardly a strong protection.

You are right in this regard, but can be mitigated by reading PKGBUILD and checking out what it is doing and loading before building anything. ;-)
Only one thing to note AUR is not Mainline Repo and should be used with caution, same can be said when compiling from source.
Check before building/compiling.... that's the beauty of *nix the user is in charge and can decide for him/her self.

[as400]

To all the people with no GPU acceleration on Wayland with newest Caidao/Chromium builds.

There is a simple workaround. Just add "--use-gl=egl" to your Caidao startup script or to ".config/caidao-flags.conf" (when using Caidao), ".config/chromium-flags.conf" (when using Chromium).

This is how chrome://gpu should look like with GPU acceleration properly enabled.