Package Details: ungoogled-chromium 79.0.3945.130-1

Git Clone URL: (read-only, click to copy)
Package Base: ungoogled-chromium
Description: A lightweight approach to removing Google web service dependency
Upstream URL:
Keywords: blink browser privacy web
Licenses: BSD
Conflicts: chromium
Provides: chromium
Submitter: ilikenwf
Maintainer: seppia
Last Packager: seppia
Votes: 121
Popularity: 6.59
First Submitted: 2016-12-19 08:08
Last Updated: 2020-01-18 10:57

Dependencies (52)

Required by (60)

Sources (4)

Pinned Comments

seppia commented on 2019-04-07 18:31

There have been made some changes in ungoogled-chromium and there now is a separate git repository handling archlinux packaging and building. There are some concerns about the decisions that must be done reguarding the versioning scheme in paritcular. You could read about it in details here . I've always followed upstream versioning because that was ideal, also for AUR PKGBUILD, but now, as already stated, some concerns have been risen. I'm honestly a bit confused and it's not very clear to me which solution would be better to adopt. I would like to know your opinion in merit, what this community thinks about it and I encourage and very much appreciate any direct involvement from anyone interested on github repo and issue.

seppia commented on 2018-12-12 21:34

Please do NOT flag this package as out of date in relation to official chromium releases.

This is NOT Google Chromium and new releases come after additional work of the ungoogled-chromium contributors, so they may not be ready, nor available for days or even weeks after a new version of official chromium is released.

Please refer to for ungoogled-chromium releases. Use those and please flag this package as out of date only if a newer release is present there. I will update the PKGBUILD as soon as I can every time a new release comes out.


Latest Comments

1 2 3 4 5 6 ... Next › Last »

sorice1123 commented on 2020-01-25 21:32


I read the mailing list but I am confused. Is the problem repackaging of a .pkg.tar file plus the binary is not official? Then (1) we just need to make it .tar.gz (2) make it built in the official repo. I think that's pretty possible.

JstKddng commented on 2020-01-22 12:39


Other trusted users agree with eshwarts decision, so can't do anything about it. They did say someone could recreate it if possible, so go ahead if you want. Here's the mirror of that package:

solnce commented on 2020-01-22 11:18

JstKddng commented on 2020-01-20 19:07


// You already know about my repository, there really isn't a shorter way about it.

// Next, the OBS is needed as a build box, nothing else, not everyone has a 16 core 32 t rig in order to build this. And I don't think it could be adopted to the main repositories as Arch tries to keep the packages as pristine as possible, as in, without any non-REQUIRED patches.

// Finally, you could take that recommendation to the aur-general mailing list, they will probably just tell you to just open an orphan request if the current owner doesn't update promptly.


I just don't see any way possible to have an ungoogled-chromium-bin package which would not require repackaging and don't be a pain when some library gets updated which breaks some binary because it was linked to the older version. I've gone through that, it's not entertaining.

Regarding the OBS, Eloston could ditch the ungoogled-chromium-binaries organization and just switch to an organization in the OBS.

Rowisi commented on 2020-01-20 18:06

@bsdice they have already a build server for AUR but only trusted users can use it, chromium-vaapi-bin uses it (which it downloads the compiled chromium-vaapi package from

We need a trusted user to create ungoogled-chromium-bin package and then he can add someone to maintain the package (@seppia or @jstKddng)

Or else we have no choice but to make a common OBS package for everyone like the maintainer of icecat did.

bsdice commented on 2020-01-20 14:06

TLDR: My gripe here is the continuing departure from Arch in-universe methods of delivering this package. Everyone contributing to this package is creating value, but that comes with another single point of failure. Shouldn't this be improved?

// The critical chain is getting really long. Chromium -> Eloston Github -> JstKddng Github -> Rowisi Github -> Opensuse Build Service -> User download and usage. Looks very scary. Any way to shorten this?

// Why is OBS even needed? What would it take to have the package in the community repo? No trusted user liking this package enough? One would think Google the company has damaged Chromium enough already to make a desktop Linux user switch to this package.

// Since the internet browser is the most security-critical component in any modern Linux desktop, I cannot with good conscience roll this out to friends and family Linux desktops. I would really want to. Having compiled this package over 20 times myself, I get that this is one complicated beast. Also on a long enough time scale, people go away. They switch distributions, marry, die, take up shrimp farming instead whatever. What we lack in AUR here is what Github has made big:

  • projects can be run by a group not single persons, to increase the bus factor above 1

  • pull requests for contributions, to lighten maintainer workload

  • continuuous integration, to automate new builds for distribution

// Does Arch need more money for infrastructure to make this happen?

Rowisi commented on 2020-01-20 13:06

@treeshateorcs I don't think its possible with OBS. its only possible if a build service has SSH support so I can add my github's SSH key and download UE source from command line.

treeshateorcs commented on 2020-01-20 12:45


would be super cool, if you somehow would make unreal engine built on obs, but i don't think it's feasible, given that it's behind a closed access repo

Rowisi commented on 2020-01-20 12:42

@ijann glad it helped.

I have made a github repo to show what changes I've made to PKGBUILD to make it work on OBS:

I am also planning to add more packages soon :)

ijann commented on 2020-01-19 18:46

thanks @Rowisi