Manjaro and Arch repository with privacy oriented software
#51
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.
  Reply
#52
@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 .
  Reply
#53
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.
  Reply
#54
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...
  Reply
#55
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.
  Reply
#56
No offence taken Smile

You have a point. I understand it.
  Reply
#57
(09-21-2020, 07:58 AM)as365n4 Wrote: 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.
  Reply
#58
@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 :)
  Reply
#59
(09-23-2020, 08:13 AM)e-v Wrote:
(09-21-2020, 07:58 AM)as365n4 Wrote: 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.
  Reply
#60
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.


[Image: ezxyfOy.png]
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Manjaro Sway Theme Broken Eighty8 1 172 03-08-2024, 08:41 AM
Last Post: tophneal
Question Manjaro with Full Disk Encryption and GRUB dumetrulo 1 1,611 02-02-2024, 02:45 AM
Last Post: frankkinney
  Manjaro network problem late 2023 acruhl 1 223 01-19-2024, 11:32 PM
Last Post: Kevin Kofler
  By the way, yay arch... KC9UDX 3 513 12-24-2023, 09:53 AM
Last Post: KC9UDX
  Help installing Manjaro on eMMC of Pinebook Pro pine4546464 4 1,923 12-13-2023, 07:22 PM
Last Post: trillobite
  Need Help Recovering Manjaro /boot Contents on Pinebook Pro calinb 6 1,983 12-11-2023, 03:47 AM
Last Post: calinb
  Manjaro 20.04 not loading from SD (with Manjaro on eMMC) zaius 1 296 12-07-2023, 03:11 PM
Last Post: wdt
  Manjaro ARM: enabling external monitors & fixing Broadcom WiFi after updating trifleneurotic 2 752 11-14-2023, 10:57 AM
Last Post: trifleneurotic
  Manjaro [ARM Stable Update] 2021-07-23 issues Bocanila 1 1,916 08-21-2023, 09:10 PM
Last Post: vanessadonald
  [Manjaro] u-boot won't boot from eMMC with (unbootable) SD card present zackw 1 1,855 08-21-2023, 09:08 PM
Last Post: vanessadonald

Forum Jump:


Users browsing this thread: 1 Guest(s)