Ungoogled-chromium: Making an ebuild for Gentoo

[unicornlover89]

I don't think this has been done yet, but I'll try and make an ebuild for gentoo and possibly publish it if no one else has yet. Let me know if this has or hasn't been done. Thanks!

[Eloston]

I don't know of anyone else that is doing or has done this. Feel free to proceed.

[rburcham]

@basilthegreat have you had success? I'm happy to help too.

[ghost]

I'm making one for my overlay. You can follow the issue tracker here. I hope to have a working ebuild in a few days.

[stefantalpalaru]

www-client/ungoogled-chromium-69.0.3497.100.1 is available in my overlay: https://github.com/stefantalpalaru/gentoo-overlay

Please test it.

[ghost]

I'm happy to announce that we have an ebuild that _strictly_ follows ungoogled-chromium's GN flags. However, I haven't tested all USE flags, the issue tracker (link above) has a detailed list of which ones need to be tested. _Enjoy!_

[stefantalpalaru]

a ebuild that strictly follows ungoogled-chromium's GN flags

If you really wanted that, you should have used the provided script to generate them, like Arch Linux does: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ungoogled-chromium&id=5952aa489b6954319455bf08adfb7783c3e237c7#n119

[unicornlover89]

@rburcham I work on this intermittently, so far i'm still figuring out how to build normally on my gentoo m achine :P

[perfect7gentleman]

Have both of you tested your ebuilds?

[stefantalpalaru]

Of course. I've been running ungoogled-chromium since I got the ebuild working, but don't expect me to test every possible combination of USE flags. My build has these enabled: "cups proprietary-codecs suid system-icu system-libvpx tcmalloc".

[powerman]

don't expect me to test every possible combination of USE flags

There is dev-python/ebuildtester to make such testing automated and easier. Of course, no one expects you to manually test how it works with each USE flags combination, but at least you should be sure it's able to build.

[ghost]

www-client/ungoogled-chromium-bin is available now, which uses the binaries published by @intika.

[perfect7gentleman]

v70 ebuild thanks to @ian-moone

[stefantalpalaru]

How can you release a version 70 when the most recent tag is for 69.0.3497.100-2?

https://github.com/Eloston/ungoogled-chromium/tags

If you're forking the project to apply the patchset to unsupported Chromium versions, you need to rename the package.

[perfect7gentleman]

master

[intika]

@stefantalpalaru
@Eloston just merged v70 to the master project... i guess @perfect7gentleman is building master... it's a super devel package but it should work... but indeed v70 of uc is not yet released

i am always fascinated to see how most of people always wants the latest release no matter what ^^

[perfect7gentleman]

@intika, but it works :)

[stefantalpalaru]

We have live ebuilds for that. Make it ungoogled-chromium-9999.ebuild and there will be no ambiguity about its stability or upstream support.

[perfect7gentleman]

Do not agree.
```
version: Update to 70.0.3538.67

[rburcham]

Yeah bleeding edge really should be a 9999 ebuild. At least that's what I'm renaming it to in my overlay.

[ghost]

Do not agree.

I hope it's just you. Based on the commit history in your repo, all your ebuilds should be renamed to *-9999.

[perfect7gentleman]

there are just lots of testing, typos and etc.
also I don't force anyone to use my overlay.

[ghost]

We have a proper 70.0.3538.67_pre* ebuild available now. _Have fun!_

[stefantalpalaru]

Nice job on the patches and new USE flags!

Why not change installation directories and binary name so you can keep Chromium installed at the same time? Since this is a fork, it also makes more sense to rename the binary to the name of the fork.

Also, is "!<" any different from the established ">=" in RDEPEND?

[ghost]

Nice job on the patches and new USE flags!

Thank you.

Why not change installation directories and binary name so you can keep Chromium installed at the same time? Since this is a fork, it also makes more sense to rename the binary to the name of the fork.

Yeah, I really thought about that, and almost followed that path, but then after I read the README, it states, _"Unlike other Chromium forks that have their own visions of a web browser, ungoogled-chromium is essentially a drop-in replacement for Chromium"_, and seeing how ungoogled-chromium is distributed for other distros, I decided to not divert from them.

However, I don't mind to maintain an USE flag (chromium-compat ?!), that would let the user install it with vanilla chromium, but I'm not willing to test it myself. If anyone is interested in this, I will ask that person to help me.

Also, is "!<" any different from the established ">=" in RDEPEND?

Yes, using >= makes it dependent on >=x11-drivers/nvidia-drivers-331.20. !< just block it, not necessarily depend on it.

[stefantalpalaru]

"firefox-bin" is a drop-in replacement for "firefox", but they have different binary names so they can be installed side by side. This gives more freedom to the user and clearly differentiates the packages.

[Eloston]

@stefantalpalaru Could you describe a use-case for having both Chromiums installed to the system? It seems contradictory to me to have both installed.

[stefantalpalaru]

I had a real use for it, a few days ago. "The Great Suspender" extension was not working on ungoogled-chromium, so I tried to remove it and install it again. Unfortunately, the removal process led to all suspended tabs being lost. I had to copy back the relevant db file from backup, start Chromium, unsuspend all tabs and only then upgrade the extension. It still doesn't work on ungoogled, for some reason.

I also noticed that ungoogled-chromium has no access to the app store, so if you want to install an extension from there, you have to use Chromium.

[Eloston]

@stefantalpalaru

"The Great Suspender" extension was not working on ungoogled-chromium

This may be a bug with ungoogled-chromium. If you could file a new issue for this, that would be much appreciated.

I also noticed that ungoogled-chromium has no access to the app store, so if you want to install an extension from there, you have to use Chromium.

This is not true. The first question of the FAQ addresses this concern. In terms of updating extensions, users have proposed multiple external solutions for this problem (in issues somewhere), but I believe the best solution is #285.

So far, the issues you described are all addressable in ungoogled-chromium. Are there any other use-cases you have? As @ian-moone pointed out, it is a top priority to retain the Chromium experience, including the packaging.

[ghost]

Regarding the install compatibility with vanilla www-client/chromium, I decided that I will be adding the USE flag chromium-compat (disabled by default, of course) in near future. There's an issue tracker for those who want to contribute.