Ungoogled-chromium: Need for trustable binaries

[playgithub]

1. Incremental building is not supported, so after every update, it takes 3+ hours to build ungoogled-chromium, there are many users, so it wastes a lot of time and resources

2. If a reproducible binary is hard, I'd like to trust an offical one, i.e. trusted by the author of ungoogled-chromium

Thanks

[PF4Public]

incremental building is not supported

One could use ccache, but I must admit, lately it rebuilds more, Google must have made something with the codebase to make it ccache unfriendly :(

[TheJags]

I'm not a developer so please pardon my ignorance but can GitHub auto generate .deb for Debian/Ubuntu or .exe for Windows with each new releases or no?

Like you can download .apk (for few different architectures) on this Iceraven's (Firefox fork for Android) GitHub releases page: https://github.com/fork-maintainers/iceraven-browser/releases

Thanks.

[rany2]

https://github.com/flathub/flathub/pull/1857

I think a flatpak would be trustworthy. Especially considering it's sandboxed, only has access to your ~/Downloads by default and is from a trustworthy repo (flathub). It comes with the ability to build for multiple archs (currently x64 and arm64)

However this doesn't help users using Windows, Android, etc.

[wchen342]

@Eloston is contacting some server providers for a building server. If we can get a server than we can use Actions to build the binaries. See the context here.

Also Debian-based binaries are built on OBS as well as Arch Linux versions. They are openly available although you do need to trust the maintainers @braewoods and @jstkdng to some degree.

[PF4Public]

Also Gentoo has binary releases ;)

[TheJags]

@wchen342 in regards to Debian-based binaries on OBS, could you please tell us, who updates them, and more importantly what those binaries depends on... 'coz on other GitHub repo braewoods replied:

"We already know. It takes a long time for Debian to update their files for new chromium releases."

Does that mean Debian project or Ubuntu gets involved in publishing these Ungoogled Chromium binaries... I was under impression that these GitHub repos are developed and maintained by Elostion, and other contributors without any participation from Debian / Ubuntu projects.

Thanks alot.

[wchen342]

I think he used the debian package as a base and apply ungoogled-chromium patches to it, so he needs to wait until upstream realease new packages. Can you confirm @braewoods?

[jstkdng]

I also do just that, use a base pkgbuild and add uc patches to it. Since arch does minimal changes compared to debian, new versions tend to come out as soon as they are available.
The trust issue still remains though.

[TheJags]

I think he used the debian package as a base and apply ungoogled-chromium patches to it, so he needs to wait until upstream realease new packages.

@wchen342

Thank you for clearing this up.

[braewoods]

@wchen342 @TheJags debian_sid is derived from the Debian chromium package repository and all the other branches are likewise derived from debian_sid. Updates are delayed due to how slow Debian is to release updated patches for new Chromium releases.

It was like this before I started getting involved and at this point I am starting to wonder if we should just devise our own packaging so we aren't chronically delayed like this every single time there is a major release. Is what we get back from Debian worth this recurring delay?

[PF4Public]

if we should just devise our own packaging so we aren't chronically delayed like this every single time there is a major release.

You may follow Arch and Gentoo as they are keeping up with chromium releases rather well.
Well, that's what I do :)

[TheJags]

at this point I am starting to wonder if we should just devise our own packaging so we aren't chronically delayed like this every single time there is a major release. Is what we get back from Debian worth this recurring delay?

@braewoods does that mean you can publish .deb binaries here on GitHub releases page or on OpenSUSE OBS ?

That would be great. Thanks a lot.

[braewoods]

They're already published on OBS. The issue is with the source packages being delayed.

[TheJags]

@braewoods I meant, on OBS or here on GitHub, but without any involvement from Debian/Ubuntu at all.

Now I don't know if it's feasible or not, but earlier you said:

at this point I am starting to wonder if we should just devise our own packaging...

So I thought, you meant building complete Ungoogled Chromium .deb binaries without any involvement of Debian/Ubuntu. Thanks.

[Eloston]

@braewoods

It was like this before I started getting involved and at this point I am starting to wonder if we should just devise our own packaging so we aren't chronically delayed like this every single time there is a major release. Is what we get back from Debian worth this recurring delay?

There are a few considerations:

• I think Debian adds value with patches for system libraries (especially older libraries) and patches to use older clang. However, I do not think Debian is the only distro that uses these older libraries, so it might be possible to get many of these patches from other distros.
• If Debian picks up development in the future, it might be worthwhile to consider reconciling to reduce redundant work on our end. However, once we diverge, we risk making it difficult to reconcile with Debian in the future.

Fundamentally, there will be an increased maintenance burden if we choose to update to new Chromium ourselves. If getting new updates outweighs the increased workload for you, then by all means please update.

In my view, I am on the fence because Portable Linux is sufficient for many use-cases and updated quickly. Also, Debian may address chromium's slow updates sooner or later because their users suffer from lack of updates too.

[berkley4]

I'd suggest not waiting for debian and going ahead with a release unilaterally, then merging in debian changes once their git gets updated. I'd estimate that Debian's git pretty much lags an upstream release by 2 weeks or more, often longer.

Of course this would be more work for the maintainer, but perhaps would be the best of both worlds. We'd at least have a debianised base to work off for the next release and no long term divergence.

If maintaining git history is an issue, then couldn't some kind of debian branch be kept to merge from?

[Eloston]

I don't understand the point of OP's request. We already have binaries in ungoogled-chromium-binaries (which I have to manually approve to be posted on the website), and we have build services compile binaries for some platforms. Is there something else I'm missing here?

Closing for now.

[playgithub]

Fine, auto build is more trustable.
I trust https://github.com/ungoogled-software/ungoogled-chromium-windows, but I can not trust the pre-built binaray in the repo, because it seems that a random person builds it.