[gentoo-dev] www-client/chromium needs a new maintainer

[gentoo-dev] www-client/chromium needs a new maintainer

[Mike Gilbert]

Hi all,

I'm throwing in the towel on www-client/chromium. It just isn't any
fun to maintain, and it's making me feel guilty when I don't give it
the attention it requires.

If anyone is interested in keeping it going, please feel free to reach
out and I will do what I can to help with the transition. Full Gentoo
developer(s) would be preferred, but I could also facilitate a proxy
commit scenario. Also happy to mentor folks who want to make the
transition to full developer.

I'll stick around in #gentoo-chromium on Libra.chat for the foreseeable future.
I'll also keep bumping the chromium-based binary browsers
(google-chrome, edge, opera).

Thanks.

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]


Mike Gilbert <floppym@gentoo.org> writes:

> Hi all,
>
> I'm throwing in the towel on www-client/chromium. It just isn't any
> fun to maintain, and it's making me feel guilty when I don't give it
> the attention it requires.

I don't blame anyone for running out of stamina with chromium. It's
a massive task and thank you (and thank you to sultan) for handling it
all this time.

>
> If anyone is interested in keeping it going, please feel free to reach
> out and I will do what I can to help with the transition. Full Gentoo
> developer(s) would be preferred, but I could also facilitate a proxy
> commit scenario. Also happy to mentor folks who want to make the
> transition to full developer.
>

This becomes more pressing as the vulnerabilities pile up:
https://bugs.gentoo.org/907999.

Nobody interested at all? We have more than enough people *using* it..



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Alexe Stefan]

[-- Attachment #1: Type: text/plain, Size: 240 bytes --]

mie., 7 iun. 2023, 13:56 Sam James <sam@gentoo.org> a scris:

>
> This becomes more pressing as the vulnerabilities pile up:
> https://bugs.gentoo.org/907999.
>
> Nobody interested at all? We have more than enough people *using* it..
>
>
>

[-- Attachment #2: Type: text/html, Size: 623 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Alexe Stefan]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

My finger slipped in my last mail.
How do you see how many people are using a package?

On Wed, Jun 7, 2023 at 10:58 AM Alexe Stefan <stefanalexe48@gmail.com>
wrote:

>
>
> mie., 7 iun. 2023, 13:56 Sam James <sam@gentoo.org> a scris:
>
>>
>> This becomes more pressing as the vulnerabilities pile up:
>> https://bugs.gentoo.org/907999.
>>
>> Nobody interested at all? We have more than enough people *using* it..
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 1131 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 363 bytes --]


Alexe Stefan <stefanalexe48@gmail.com> writes:

> My finger slipped in my last mail.
> How do you see how many people are using a package?

Bug reports, mentions on forums, mentions on the mailing list, mentions
on IRC, etc.

Or, to put it another way: when you break it, enough people
shout. Gentoo doesn't have telemetry so we have to go off things like
this.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Jeff Gazso]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

I'm in the process of getting Gentoo dev status. I'm willing to consider
maintaining www-client/chromium. I have a high core count rack server that
should be able to handle the build process quite well. Can you give me a
list
of common pain points? If that is a long conversation feel free to email me
directly.

~Jeff

On Wed, Jun 7, 2023 at 7:06 AM Sam James <sam@gentoo.org> wrote:

>
> Alexe Stefan <stefanalexe48@gmail.com> writes:
>
> > My finger slipped in my last mail.
> > How do you see how many people are using a package?
>
> Bug reports, mentions on forums, mentions on the mailing list, mentions
> on IRC, etc.
>
> Or, to put it another way: when you break it, enough people
> shout. Gentoo doesn't have telemetry so we have to go off things like
> this.
>

[-- Attachment #2: Type: text/html, Size: 1229 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Toralf Förster]

[-- Attachment #1.1: Type: text/plain, Size: 235 bytes --]

On 6/7/23 15:09, Jeff Gazso wrote:
> Can you give me a list
> of common pain points?

My wish would be a -bin package.
Even with -j12 it takes here 5-6 hours compile time, which is a pain.

-- 
Toralf
PGP 23217DA7 9B888F45


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]


Toralf Förster <toralf@gentoo.org> writes:

> [[PGP Signed Part:Undecided]]
> On 6/7/23 15:09, Jeff Gazso wrote:
>> Can you give me a list
>> of common pain points?
>
> My wish would be a -bin package.
> Even with -j12 it takes here 5-6 hours compile time, which is a pain.

That's more work for the maintainer, not less. We've just last-rited
chromium-bin because manually building it is too much hassle.

Jeff is asking what makes maintaining chromium hard.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On Wed, Jun 07, 2023 at 04:12:22PM +0200, Toralf Förster wrote:
> On 6/7/23 15:09, Jeff Gazso wrote:
> > Can you give me a list
> > of common pain points?
> 
> My wish would be a -bin package.
> Even with -j12 it takes here 5-6 hours compile time, which is a pain.

We already "have" one but it's being last-rited due to lack of
of maintenance (www-client/chromium-bin).

Not that it couldn't be revived if someone has the motivation to.
Albeit always fear that such self-built -bin will just die or lag
behind again if it remains a 1-person side project.
-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Mike Gilbert]

On Wed, Jun 7, 2023 at 9:09 AM Jeff Gazso <jeff.gazso@gmail.com> wrote:
>
> I'm in the process of getting Gentoo dev status. I'm willing to consider
> maintaining www-client/chromium. I have a high core count rack server that
> should be able to handle the build process quite well. Can you give me a list
> of common pain points? If that is a long conversation feel free to email me
> directly.

I'll start by giving a brief overview of the Chromium release process upstream:

- 3 release channels: stable, beta, dev/unstable
- Major development occurs on the master branch.
- Once a month, a new major version is forked from master, and this
becomes the "dev channel" release series.
- Over the next several weeks in the dev channel the major version is
tested and fixed, with releases roughly once per week.
- Eventually, the branch is promoted to the "beta channel".
- A similar process occurs in the beta channel, with weekly releases
until the major version is finally promoted to the "stable channel".
- The stable channel sees around 1 to 2 releases per month, usually
with security fixes included.

Downstream, we have historically tried to keep up with all 3 channels.
Keeping the dev channel working is the biggest challenge. The other
channels usually just involve build testing and the occasional
backport of fixes.

Common problems:

- Across the 3 channels, you are looking at roughly 12 releases per
month. That's a lot of churn.
- The dev channel never compiles the first time you try it. There are
always problems to fix.
- Upstream only really supports using their bundled toolchain (an LLVM
git snapshot on Ubuntu). On Gentoo, we try to make it work with the
stable release of GCC and LLVM/clang.
- Upstream likes to use modern C++ features, and they write C++ code
that tends to break or is unsupported on stable releases of GCC and
LLVM.
- Upstream bundles many libraries. The Gentoo ebuild has some logic to
unbundle a number of these, but maintaining it is a pain.
- Using the bundled libraries sometimes is problematic, especially on
non-x86-64 targets which upstream doesn't support well.
- Upstream cross-compiles their ARM binaries, whereas we compile
natively on Gentoo. This sometimes causes conflicts.

I'm probably missing some things, but I think that should give you
some idea of what you're in for. :-)

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Maciej Barć]

[-- Attachment #1.1.1: Type: text/plain, Size: 3301 bytes --]

I think Google does all this intentionally to piss off people trying to 
use the "free-er" version of Chrome... let's face it, "their" aim is to 
create a one-fits-all spyware named Google Chrome.

Google does not want you to touch their mess.
Google does not want you to even think about going a extra mile to not 
have telemetry in software you use every day.

Having said all this, it really is a miracle to me that the Gentoo 
Chromium team had put up with this for so insanely long and I have the 
most respect for you guys!

W dniu 7.06.2023 o 19:45, Mike Gilbert pisze:
> On Wed, Jun 7, 2023 at 9:09 AM Jeff Gazso <jeff.gazso@gmail.com> wrote:
>>
>> I'm in the process of getting Gentoo dev status. I'm willing to consider
>> maintaining www-client/chromium. I have a high core count rack server that
>> should be able to handle the build process quite well. Can you give me a list
>> of common pain points? If that is a long conversation feel free to email me
>> directly.
> 
> I'll start by giving a brief overview of the Chromium release process upstream:
> 
> - 3 release channels: stable, beta, dev/unstable
> - Major development occurs on the master branch.
> - Once a month, a new major version is forked from master, and this
> becomes the "dev channel" release series.
> - Over the next several weeks in the dev channel the major version is
> tested and fixed, with releases roughly once per week.
> - Eventually, the branch is promoted to the "beta channel".
> - A similar process occurs in the beta channel, with weekly releases
> until the major version is finally promoted to the "stable channel".
> - The stable channel sees around 1 to 2 releases per month, usually
> with security fixes included.
> 
> Downstream, we have historically tried to keep up with all 3 channels.
> Keeping the dev channel working is the biggest challenge. The other
> channels usually just involve build testing and the occasional
> backport of fixes.
> 
> Common problems:
> 
> - Across the 3 channels, you are looking at roughly 12 releases per
> month. That's a lot of churn.
> - The dev channel never compiles the first time you try it. There are
> always problems to fix.
> - Upstream only really supports using their bundled toolchain (an LLVM
> git snapshot on Ubuntu). On Gentoo, we try to make it work with the
> stable release of GCC and LLVM/clang.
> - Upstream likes to use modern C++ features, and they write C++ code
> that tends to break or is unsupported on stable releases of GCC and
> LLVM.
> - Upstream bundles many libraries. The Gentoo ebuild has some logic to
> unbundle a number of these, but maintaining it is a pain.
> - Using the bundled libraries sometimes is problematic, especially on
> non-x86-64 targets which upstream doesn't support well.
> - Upstream cross-compiles their ARM binaries, whereas we compile
> natively on Gentoo. This sometimes causes conflicts.
> 
> I'm probably missing some things, but I think that should give you
> some idea of what you're in for. :-)
> 

-- 
Have a great day!

~ Maciej XGQT Barć

xgqt@gentoo.org
Gentoo Linux developer
(dotnet, emacs, math, ml, nim, scheme, sci)
https://wiki.gentoo.org/wiki/User:Xgqt
9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 10875 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Jeff Gazso]

[-- Attachment #1: Type: text/plain, Size: 4690 bytes --]

That does sound painful.

> - Across the 3 channels, you are looking at roughly 12 releases per
month.
> That's a lot of churn.

* Why build unstable stuff, why not build only stable releases and fix the
problems once?

* Looking at chromium-browser-official and the GitHub mirror, it's unclear
to
me which release is stable. How is that sorted out?

> - Upstream likes to use modern C++ features, and they write C++ code that
> tends to break or is unsupported on stable releases of GCC and LLVM.

* How common of a problem is the C++ issue?

* I don't know C++, is that a major obstacle?

> - Upstream bundles many libraries. The Gentoo ebuild has some logic to
> unbundle a number of these, but maintaining it is a pain.

* What tends to go wrong?

> - Using the bundled libraries sometimes is problematic, especially on
> non-x86-64 targets which upstream doesn't support well.

* What tends to break here?

* Is the upstream likely to take patches or are we stuck maintaining a
patch
set for pretty much all non-x86-64 targets?

* Is this why Sam maintains a bunch of PPC64 patches? Do these ever make
their way upstream?

~Jeff

On Wed, Jun 7, 2023 at 2:38 PM Maciej Barć <xgqt@gentoo.org> wrote:

> I think Google does all this intentionally to piss off people trying to
> use the "free-er" version of Chrome... let's face it, "their" aim is to
> create a one-fits-all spyware named Google Chrome.
>
> Google does not want you to touch their mess.
> Google does not want you to even think about going a extra mile to not
> have telemetry in software you use every day.
>
> Having said all this, it really is a miracle to me that the Gentoo
> Chromium team had put up with this for so insanely long and I have the
> most respect for you guys!
>
> W dniu 7.06.2023 o 19:45, Mike Gilbert pisze:
> > On Wed, Jun 7, 2023 at 9:09 AM Jeff Gazso <jeff.gazso@gmail.com> wrote:
> >>
> >> I'm in the process of getting Gentoo dev status. I'm willing to consider
> >> maintaining www-client/chromium. I have a high core count rack server
> that
> >> should be able to handle the build process quite well. Can you give me
> a list
> >> of common pain points? If that is a long conversation feel free to
> email me
> >> directly.
> >
> > I'll start by giving a brief overview of the Chromium release process
> upstream:
> >
> > - 3 release channels: stable, beta, dev/unstable
> > - Major development occurs on the master branch.
> > - Once a month, a new major version is forked from master, and this
> > becomes the "dev channel" release series.
> > - Over the next several weeks in the dev channel the major version is
> > tested and fixed, with releases roughly once per week.
> > - Eventually, the branch is promoted to the "beta channel".
> > - A similar process occurs in the beta channel, with weekly releases
> > until the major version is finally promoted to the "stable channel".
> > - The stable channel sees around 1 to 2 releases per month, usually
> > with security fixes included.
> >
> > Downstream, we have historically tried to keep up with all 3 channels.
> > Keeping the dev channel working is the biggest challenge. The other
> > channels usually just involve build testing and the occasional
> > backport of fixes.
> >
> > Common problems:
> >
> > - Across the 3 channels, you are looking at roughly 12 releases per
> > month. That's a lot of churn.
> > - The dev channel never compiles the first time you try it. There are
> > always problems to fix.
> > - Upstream only really supports using their bundled toolchain (an LLVM
> > git snapshot on Ubuntu). On Gentoo, we try to make it work with the
> > stable release of GCC and LLVM/clang.
> > - Upstream likes to use modern C++ features, and they write C++ code
> > that tends to break or is unsupported on stable releases of GCC and
> > LLVM.
> > - Upstream bundles many libraries. The Gentoo ebuild has some logic to
> > unbundle a number of these, but maintaining it is a pain.
> > - Using the bundled libraries sometimes is problematic, especially on
> > non-x86-64 targets which upstream doesn't support well.
> > - Upstream cross-compiles their ARM binaries, whereas we compile
> > natively on Gentoo. This sometimes causes conflicts.
> >
> > I'm probably missing some things, but I think that should give you
> > some idea of what you're in for. :-)
> >
>
> --
> Have a great day!
>
> ~ Maciej XGQT Barć
>
> xgqt@gentoo.org
> Gentoo Linux developer
> (dotnet, emacs, math, ml, nim, scheme, sci)
> https://wiki.gentoo.org/wiki/User:Xgqt
> 9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C
>

[-- Attachment #2: Type: text/html, Size: 5755 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]


Jeff Gazso <jeff.gazso@gmail.com> writes:

> That does sound painful.
>
>> - Across the 3 channels, you are looking at roughly 12 releases per month. 
>> That's a lot of churn.
>
> * Why build unstable stuff, why not build only stable releases and fix the 
> problems once?

The idea is that you end up fixing stuff before you have a big mountain
of things to fix in stable. I don't know if that's necessary nowadays
or not, but that's the concept, I think.

>
> * Looking at chromium-browser-official and the GitHub mirror, it's unclear to 
> me which release is stable. How is that sorted out?
>

The chrome release blog announces the changes.

>> - Upstream likes to use modern C++ features, and they write C++ code that 
>> tends to break or is unsupported on stable releases of GCC and LLVM.
>
> * How common of a problem is the C++ issue? 
>

Depends on if we want to keep GCC working.

> * I don't know C++, is that a major obstacle?
>

You will need to know at least a little bit (or learn it) to fix problems.

>> - Upstream bundles many libraries. The Gentoo ebuild has some logic to 
>> unbundle a number of these, but maintaining it is a pain.
>
> * What tends to go wrong?
>
>> - Using the bundled libraries sometimes is problematic, especially on
>> non-x86-64 targets which upstream doesn't support well.
>
> * What tends to break here?
>

https://bugs.gentoo.org/904850 was an example of an arm64-only bug,
although it was an easy fix.

> * Is the upstream likely to take patches or are we stuck maintaining a patch 
> set for pretty much all non-x86-64 targets?
>
> * Is this why Sam maintains a bunch of PPC64 patches? Do these ever make 
> their way upstream?

I don't maintain those - that's somebody else.

The PPC64 patches originate from Raptor who produce PPC64 workstations
and I think the community helps maintain them. Upstream tend to not want
patches for things they can't test in CI.

(Also, please don't top-post - quote and reply underneath an email.)

>k

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Mike Gilbert]

On Wed, Jun 7, 2023 at 3:25 PM Jeff Gazso <jeff.gazso@gmail.com> wrote:
>
> That does sound painful.
>
> > - Across the 3 channels, you are looking at roughly 12 releases per month.
> > That's a lot of churn.
>
> * Why build unstable stuff, why not build only stable releases and fix the
> problems once?

That's certainly an option. The downside is stable releases almost
always fix security issues, so you are "under the gun" at that point.

> * Looking at chromium-browser-official and the GitHub mirror, it's unclear to
> me which release is stable. How is that sorted out?

Some links for you:

https://chromiumdash.appspot.com/releases?platform=Linux
https://chromereleases.googleblog.com/

> > - Upstream likes to use modern C++ features, and they write C++ code that
> > tends to break or is unsupported on stable releases of GCC and LLVM.
>
> * How common of a problem is the C++ issue?

There are usually some issues with every major Chromium version.

> * I don't know C++, is that a major obstacle?

Yes; you would at least need to teach yourself enough of the language
to attempt to interpret compiler error message.

> > - Upstream bundles many libraries. The Gentoo ebuild has some logic to
> > unbundle a number of these, but maintaining it is a pain.
>
> * What tends to go wrong?

- Version mismatches: upstream expects a different version of the
library than we have stable on Gentoo.
- Custom patching: sometimes Chromium forks/patches the bundled
library and there is a delay in sending those changes upstream (if it
ever happens).
- Chromium source files sometimes refer to the bundled header files
directly (#include "third_party/mylib/mylib.h") instead of using a
generic path like #include <mylib.h>.

> > - Using the bundled libraries sometimes is problematic, especially on
> > non-x86-64 targets which upstream doesn't support well.
>
> * What tends to break here?

For example, take ffmpeg. The bundled library uses a pre-configured
copy of ffmpeg, which can break depending on the user's system. At a
minimum, we need to reconfigure the bundled ffmpeg to work properly.

> * Is the upstream likely to take patches or are we stuck maintaining a patch
> set for pretty much all non-x86-64 targets?

Upstream supports x86-64 and ARM only. All other targets require
distro patching.

> * Is this why Sam maintains a bunch of PPC64 patches? Do these ever make
> their way upstream?

Yes, this is why we have a PPC64 patchset (which we mostly steal from
Raptor Computing).

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Alexe Stefan]

[-- Attachment #1: Type: text/plain, Size: 4718 bytes --]

I don't use chromium and I don't know what release cycle it has, but can't
those interested in running chromium use an ebuild that tracks the git tree
and updates after every change.
The maintenance burden would be minimal, and any patches could be applied
with /etc/portage/patches.
If something like this isn't suitable for ::gentoo, it can be added to a
personal overlay.
If the upstream release cycle is too fast, someone could fork the repo and
update the fork as slow as desired.
Maybe something like this:
# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the MIT License

EAPI=8

DESCRIPTION="The chromium browser"
HOMEPAGE="https://github.com/chromium/chromium"
EGIT_REPO_URI="https://github.com/chromium/chromium.git"
inherit git-r3

LICENSE="BSD-3"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE=""

DEPEND="|| (    sys-devel/gcc
                sys-devel/clang )"
RDEPEND="${DEPEND}"
BDEPEND=""

src_configure() {
chromium_configure
}

src_install() {
chromium_compile

mv out/Release/chromedriver{.unstripped,} || die

rm -f out/Release/locales/*.pak.info || die

# Build manpage; bug #684550
sed -e 's|@@PACKAGE@@|chromium-browser|g;
s|@@MENUNAME@@|Chromium|g;' \
chrome/app/resources/manpage.1.in > \
out/Release/chromium-browser.1 || die

# Build desktop file; bug #706786
sed -e 's|@@MENUNAME@@|Chromium|g;
s|@@USR_BIN_SYMLINK_NAME@@|chromium-browser|g;
s|@@PACKAGE@@|chromium-browser|g;
s|\(^Exec=\)/usr/bin/|\1|g;' \
chrome/installer/linux/common/desktop.template > \
out/Release/chromium-browser-chromium.desktop || die

# Build vk_swiftshader_icd.json; bug #827861
sed -e 's|${ICD_LIBRARY_PATH}|./libvk_swiftshader.so|g' \
third_party/swiftshader/src/Vulkan/vk_swiftshader_icd.json.tmpl > \
out/Release/vk_swiftshader_icd.json || die
}

Also, with all this discussion, one can't help but wonder, is
firefox/librewolf also in such danger?


On Wed, Jun 7, 2023 at 7:49 PM Mike Gilbert <floppym@gentoo.org> wrote:

> On Wed, Jun 7, 2023 at 3:25 PM Jeff Gazso <jeff.gazso@gmail.com> wrote:
> >
> > That does sound painful.
> >
> > > - Across the 3 channels, you are looking at roughly 12 releases per
> month.
> > > That's a lot of churn.
> >
> > * Why build unstable stuff, why not build only stable releases and fix
> the
> > problems once?
>
> That's certainly an option. The downside is stable releases almost
> always fix security issues, so you are "under the gun" at that point.
>
> > * Looking at chromium-browser-official and the GitHub mirror, it's
> unclear to
> > me which release is stable. How is that sorted out?
>
> Some links for you:
>
> https://chromiumdash.appspot.com/releases?platform=Linux
> https://chromereleases.googleblog.com/
>
> > > - Upstream likes to use modern C++ features, and they write C++ code
> that
> > > tends to break or is unsupported on stable releases of GCC and LLVM.
> >
> > * How common of a problem is the C++ issue?
>
> There are usually some issues with every major Chromium version.
>
> > * I don't know C++, is that a major obstacle?
>
> Yes; you would at least need to teach yourself enough of the language
> to attempt to interpret compiler error message.
>
> > > - Upstream bundles many libraries. The Gentoo ebuild has some logic to
> > > unbundle a number of these, but maintaining it is a pain.
> >
> > * What tends to go wrong?
>
> - Version mismatches: upstream expects a different version of the
> library than we have stable on Gentoo.
> - Custom patching: sometimes Chromium forks/patches the bundled
> library and there is a delay in sending those changes upstream (if it
> ever happens).
> - Chromium source files sometimes refer to the bundled header files
> directly (#include "third_party/mylib/mylib.h") instead of using a
> generic path like #include <mylib.h>.
>
> > > - Using the bundled libraries sometimes is problematic, especially on
> > > non-x86-64 targets which upstream doesn't support well.
> >
> > * What tends to break here?
>
> For example, take ffmpeg. The bundled library uses a pre-configured
> copy of ffmpeg, which can break depending on the user's system. At a
> minimum, we need to reconfigure the bundled ffmpeg to work properly.
>
> > * Is the upstream likely to take patches or are we stuck maintaining a
> patch
> > set for pretty much all non-x86-64 targets?
>
> Upstream supports x86-64 and ARM only. All other targets require
> distro patching.
>
> > * Is this why Sam maintains a bunch of PPC64 patches? Do these ever make
> > their way upstream?
>
> Yes, this is why we have a PPC64 patchset (which we mostly steal from
> Raptor Computing).
>
>

[-- Attachment #2: Type: text/html, Size: 6091 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 1311 bytes --]

On 8.6.2023 1.11, Alexe Stefan wrote:
> 
> Also, with all this discussion, one can't help but wonder, is
> firefox/librewolf also in such danger?
> 
> 

Maintaining Firefox shares many of the bullet points mentioned above. We
used to provide alpha/beta builds so issues would be caught early and
reported upstream before a release was made. Luckily few years ago
Mozilla invested in a pretty efficient CI system where they now test
commits/releases using multiple different setups; for example, multiple
different llvm releases, gcc etc. That does relieve us from some burden,
but obviously Gentoo ships Firefox with multiple configure options and
something is bound to be broken every now and then. We've made the
choice of only stabilizing the ESR release which takes some pressure
off, because ESR is usually pretty stable between minor releases.

They also happily welcome patches to fix any issues, although new
features may not get in without strong reasoning first.

I'd also like to credit previous Firefox's maintainers in Gentoo who've
historically been active and done a good job while having close ties
with upstream. I'm glad upstream mostly takes us seriously, even with
our ability to heavily customize the build outcome.

Let's hope this doesn't change.

-- juippis

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Alexe Stefan]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

Can you build firefox/librewolf with gcc?
Afaik, you can only build it with clang/llvm.
Librewolf if the only reason I have clang and llvm on my system.

joi, 8 iun. 2023, 10:31 Joonas Niilola <juippis@gentoo.org> a scris:

> Luckily few years ago
> Mozilla invested in a pretty efficient CI system where they now test
> commits/releases using multiple different setups; for example, multiple
> different llvm releases, gcc etc.
>

[-- Attachment #2: Type: text/html, Size: 787 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 791 bytes --]

On 8.6.2023 13.08, Alexe Stefan wrote:
> Can you build firefox/librewolf with gcc?
> Afaik, you can only build it with clang/llvm.
> Librewolf if the only reason I have clang and llvm on my system.
> 
> joi, 8 iun. 2023, 10:31 Joonas Niilola <juippis@gentoo.org
> <mailto:juippis@gentoo.org>> a scris:
> 
>     Luckily few years ago
>     Mozilla invested in a pretty efficient CI system where they now test
>     commits/releases using multiple different setups; for example, multiple
>     different llvm releases, gcc etc.
> 

Unfortunately Firefox does link to libclang for the web developer tools,
syntax highlight etc so a clang dep is mandatory. You can fully build
the source using GCC though.

No idea about LibreWolf, but I'd imagine it's similar.

-- juippis

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] www-client/chromium needs a new maintainer

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]


Alexe Stefan <stefanalexe48@gmail.com> writes:

> I don't use chromium and I don't know what release cycle it has, but can't those interested in running chromium use an
> ebuild that tracks the git tree and updates after every change.
> The maintenance burden would be minimal, and any patches could be applied with /etc/portage/patches. 
> If something like this isn't suitable for ::gentoo, it can be added to a personal overlay.
> If the upstream release cycle is too fast, someone could fork the repo and update the fork as slow as desired.
> Maybe something like this:
> # Copyright 1999-2023 Gentoo Authors

No, this misses the point about what's hard - keeping things
building. Let's try to keep speculation down, please. This is already a
complicated topic without guessing.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]