www-client/ungoogled-chromium: publishing in the official gentoo repo?

[fordfrog]

is there anything holding back this great package from being published in the official gentoo repository?

[PF4Public]

this great package

I take it as a compliment, thanks!

I'm glad you asked. I too sometimes ponder over the applicability of my ebuilds to mainline Gentoo.

If ungoogled-chromium is to be transferred to mainline Gentoo, it would perhaps make sense to also transfer ungoogled-chromium-bin. And then maybe cromite too since it is closely related to ungoogled-chromium. And then maybe electron? And then element and vscode? Come to think of it, at this point I believe I’m getting the hang of it, and probably every other ebuild from my overlay is worth having in mainline Gentoo.

Now back to your question. First and foremost reason is that they are literally not interested. Or should I rather say were not interested; something might’ve changed since Mike Gilbert made this statement in 2016. It could be that they were not interested in maintaining ungoogled-chromium in the first place, but if someone would’ve been willing to maintain it, the answer would’ve been different.

There is, of course, a number of other concerns (in no particular order):

• I use sed extensively instead of maintaining a ton of patches for each occasion. But I have a feeling that it is not welcome in main Gentoo repository. For me, using sed is more straightforward and convenient.
• I prefer piling patches up in files directory. Gentoo developers, it seems, prefer packing those into archives and distributing them. I find that very inconvenient.
• I have established some automation using GitHub Actions. I hope this adds to the quality of the ebuilds. I think that such automation might be unavailable (to me) in mainline Gentoo.
  • I have established testing procedures that verify various USE flag combinations for me. With that I’m almost immediately notified of breakages, which allows me to tackle them in a timely fashion (hopefully). I suspect Gentoo offers no such possibility.
  • I have established some automation to relieve me of most of the boring and repetitive tasks. Again, I suspect this would not be feasible in mainline Gentoo.
• Currently I only need to push my commits into my overlay and it’s done. Transferring ungoogled-chromium to mainline Gentoo would imply that I need to submit PRs and someone would need to review and approve them. So much extra work for limited benefit, let alone the same requirement for my automated commits. It might even do more harm than good!
• My current workflow is actually a bit weird. I don’t build ungoogled-chromium on my laptop for obvious reasons as well as I rarely build it on my desktop too. Instead, I build it “elsewhere”, and for that I need to first push commits to my overlay, pull them to “elsewhere” and attempt a build. You might be asking right now: but why? Well, because reasons! Obviously this won’t work if I transfer ungoogled-chromium to main Gentoo repository and I’ll have to either abandon this workflow, or be very creative to be able to continue as usual.
• It would be possible to rsync ungoogled-chromium folder to Gentoo periodically, but would doing so make any sense?
• It would be possible to keep all the ebuilds in the overlay and to submit only stable ones. Not sure if this would also make sense.
• I definitely would not be willing to submit ebuilds into GURU since in addition to the concerns above, there is yet another one against GURU. Packages submitted to GURU are forbidden to be marked stable. In my overlay I make use of distinction between stable, testing and masked statuses to convey this crucial information to end-users. I’m not willing to give up this opportunity.

@fordfrog I assume you are an active Gentoo Developer at the present time and perhaps have a more insightful knowledge of Gentoo infrastructure and procedures; therefore, may I ask you to be the judge for the above mentioned concerns?

[fordfrog]

this great package

I take it as a compliment, thanks!

tbh, i see your ebuild much more advanced than the chromium one in the main tree.

I'm glad you asked. I too sometimes ponder over the applicability of my ebuilds to mainline Gentoo.

If ungoogled-chromium is to be transferred to mainline Gentoo, it would perhaps make sense to also transfer ungoogled-chromium-bin. And then maybe cromite too since it is closely related to ungoogled-chromium. And then maybe electron? And then element and vscode? Come to think of it, at this point I believe I’m getting the hang of it, and probably every other ebuild from my overlay is worth having in mainline Gentoo.

if you're willing to continue to take care of them then i see no problem in that, though i use only ungoogled-chromium from your overlay myself, but others might benefit from your other packages too.

Now back to your question. First and foremost reason is that they are literally not interested. Or should I rather say were not interested; something might’ve changed since Mike Gilbert made this statement in 2016. It could be that they were not interested in maintaining ungoogled-chromium in the first place, but if someone would’ve been willing to maintain it, the answer would’ve been different.

well, according to my knowledge there were some shifts in maintenance of chromium, but i might be wrong. afaik the packages were maintained by sultan but his last commit on chromium is from august.

what i had on my mind was rather that you still maintain the ebuild(s) and i can work as your buddy on the gentoo side, for merging the ebuilds, taking care of propagating some stuff to other ebuilds (like patching ffmpeg for system-ffmpeg use flag), testing etc. i can't really maintain any of your ebuilds though 😄

There is, of course, a number of other concerns (in no particular order):

• I use sed extensively instead of maintaining a ton of patches for each occasion. But I have a feeling that it is not welcome in main Gentoo repository. For me, using sed is more straightforward and convenient.

it is preferred to use patches as it is a more robust solution, but sed has also it's usage, definitely for cases where the patch would be too large and unmaintainable anyway.

• I prefer piling patches up in files directory. Gentoo developers, it seems, prefer packing those into archives and distributing them. I find that very inconvenient.

small patches are ok in files dir but large patches or binary stuff should be hosted elsewhere to not clutter the git repo and to keep it relatively small.

• I have established some automation using GitHub Actions. I hope this adds to the quality of the ebuilds. I think that such automation might be unavailable (to me) in mainline Gentoo.

  • I have established testing procedures that verify various USE flag combinations for me. With that I’m almost immediately notified of breakages, which allows me to tackle them in a timely fashion (hopefully). I suspect Gentoo offers no such possibility.

we have automated testing too which catches many issues, but i guess yours is more specific and hence should be preserved. ago and toralf are the two running the automated tests afaik. sure we can talk to them to enhance the tests, but it depends on the development process, whether it would really make sense to contact them. i'll write on that below.

• I have established some automation to relieve me of most of the boring and repetitive tasks. Again, I suspect this would not be feasible in mainline Gentoo.

as you have a lot of stuff set up and some of it is specific to the packages you maintain, i suggest, if you (we) decide to push your ebuilds to the main tree, to keep the process the same, at least for now, and push to the main tree only the packages and versions that you approve as gentoo main tree ready. that would not require much extra work, and no changes in the workflow, the workflow just would be extended with one more step, and that is publishing the ebuilds in the main tree.

• Currently I only need to push my commits into my overlay and it’s done. Transferring ungoogled-chromium to mainline Gentoo would imply that I need to submit PRs and someone would need to review and approve them. So much extra work for limited benefit, let alone the same requirement for my automated commits. It might even do more harm than good!

i could just grab your commits from your overlay. and i can do the review to the extent that i am capable of.

• My current workflow is actually a bit weird. I don’t build ungoogled-chromium on my laptop for obvious reasons as well as I rarely build it on my desktop too. Instead, I build it “elsewhere”, and for that I need to first push commits to my overlay, pull them to “elsewhere” and attempt a build. You might be asking right now: but why? Well, because reasons! Obviously this won’t work if I transfer ungoogled-chromium to main Gentoo repository and I’ll have to either abandon this workflow, or be very creative to be able to continue as usual.

the workflow i suggest above would not change this.

• It would be possible to rsync ungoogled-chromium folder to Gentoo periodically, but would doing so make any sense?
• It would be possible to keep all the ebuilds in the overlay and to submit only stable ones. Not sure if this would also make sense.

yes, that's imo the best approach as it will create no extra work for you.

• I definitely would not be willing to submit ebuilds into GURU since in addition to the concerns above, there is yet another one against GURU. Packages submitted to GURU are forbidden to be marked stable. In my overlay I make use of distinction between stable, testing and masked statuses to convey this crucial information to end-users. I’m not willing to give up this opportunity.

@fordfrog I assume you are an active Gentoo Developer at the present time and perhaps have a more insightful knowledge of Gentoo infrastructure and procedures; therefore, may I ask you to be the judge for the above mentioned concerns?

as i mentioned inline above, i'd keep your workflow and just add one more step - pushing the ready ebuilds to the main tree. that brings some other work that will be needed though, like:

• taking care of bugs at gentoo official bugzilla for those packages, but that's rather a benefit as the packages will be more tested and more issues would be caught, and some help from the community might come too
• some use flags (those that currently don't work) would have to be at least masked (system-absail-cpp afaik unless something changed, not sure if some other too)
• we'd go through the stabilization process, but that's just filing the stabilization bug, handling the possible issues, and keeping the latest stable and the not-yet-stabilized ebuilds around
• we might need to propagate some stuff to other packages (like the ffmpeg patch)

so, to sum it up, i'm willing to help with the gentoo side stuff but i don't have the capacity to do any real maintenance of the packages. we already have many packages proxy maintained so there should be no real technical issue with that.

[PF4Public]

afaik the packages were maintained by sultan but his last commit on chromium is from august.

He has retired as far as I know.

taking care of propagating some stuff to other ebuilds (like patching ffmpeg for system-ffmpeg use flag)

This warrants a discussion with ffmpeg maintainers (who are out of reach for me probably), as they may not accept this change (Arch seems to be fine with it though).

it is preferred to use patches as it is a more robust solution

At some point I made sed to fail on no match, and replaced some of the occurrences with this improved substitution command, but not all of them unfortunately.

small patches are ok in files dir but large patches or binary stuff should be hosted elsewhere to not clutter the git repo and to keep it relatively small.

The thing is that I don't have this "elsewhere" for hosting them. Using another GitHub repository just for that looks inappropriate to me.

the workflow just would be extended with one more step, and that is publishing the ebuilds in the main tree

Exactly! I believe I can also automate submitting PRs to Gentoo repository, but that would create additional work for Gentoo Developer (you for example). Wouldn't it be superfluous since just anyone could add my overlay and pull ebuilds from here?

taking care of bugs at gentoo official bugzilla for those packages

As surprising as it may sound, it is what I already do because some of the issues come directly to Gentoo Bugzilla instead of here :D

some use flags (those that currently don't work) would have to be at least masked (system-absail-cpp afaik unless something changed, not sure if some other too)

Totally agree, I'm aware of this, but they are neglected in the overlay because I can get away with it :)

we'd go through the stabilization process, but that's just filing the stabilization bug, handling the possible issues, and keeping the latest stable and the not-yet-stabilized ebuilds around

I'm confused. Your original suggestion was to ship stable ebuilds into Gentoo, but now I suspect you want testing to be there too, am I misunderstanding you?

so, to sum it up, i'm willing to help with the gentoo side stuff

We may kindly invite Mike and Sam to our discussion then. @thesamesam, @floppym you don't need to read the whole discussion above just yet, although you may if you wish to :) I have just two questions for you for now:

• Would it make sense to push stable (in my opinion) ebuilds into mainline Gentoo via proxy-maint while still keeping all of them here? Would they be welcome there?
• Would you be able to review and suggest improvements for the ones you consider of value for mainline Gentoo? Or at least ask someone in Gentoo to do so?

[thesamesam]

This warrants a discussion with ffmpeg maintainers (who are out of reach for me probably), as they may not accept this change (Arch seems to be fine with it though).

Unless upstream want to take it, I don't think this is doable. We pride ourselves on being vanilla without gratuitious patching and changing API is not acceptable.

Ultimately, as with some other packages Chromium vendors, the version in the Chromium repository is not identical to upstream and trying to unbundle it is not as simple as build system tweaking. They expect different behaviour in some cases.

At some point I made sed to fail on no match, and replaced some of the occurrences with this improved substitution command, but not all of them unfortunately.

Understanding best practices and why we follow them is important. If you want your own standards in your repository, that's fine, but if they'll be in ::gentoo, you need to conform. We can discuss some things but I don't want to have to debate every single bit of QA policy either.

fordfrog's suggestion of just doing everything the same, including development in this repo, and just copying stuff into ::gentoo for the stable channel seems reasonable, but at the very least would need fordfrog to help with reviewing and merging PRs, as we're already struggling with effort to get @Kangie's PRs in.

[fordfrog]

small patches are ok in files dir but large patches or binary stuff should be hosted elsewhere to not clutter the git repo and to keep it relatively small.

The thing is that I don't have this "elsewhere" for hosting them. Using another GitHub repository just for that looks inappropriate to me.

i have place to host them if needed.

the workflow just would be extended with one more step, and that is publishing the ebuilds in the main tree

Exactly! I believe I can also automate submitting PRs to Gentoo repository, but that would create additional work for Gentoo Developer (you for example). Wouldn't it be superfluous since just anyone could add my overlay and pull ebuilds from here?

the main gentoo tree provides higher standards and is more trustworthy than overlays, and it is also easier to access. there are probably even more benefits.

we'd go through the stabilization process, but that's just filing the stabilization bug, handling the possible issues, and keeping the latest stable and the not-yet-stabilized ebuilds around

I'm confused. Your original suggestion was to ship stable ebuilds into Gentoo, but now I suspect you want testing to be there too, am I misunderstanding you?

well, what you consider stable (or the upstream) is not considered stable within the gentoo ecosystem. so even if you approve an ebuild for the main tree, once the ebuild gets to the main tree, there is usually 30 days period after which a stabilization request is filed and stabilization team checks the package is really ready for being marked as stable. there might be issues related to the way how we package the app etc, so this is the standard process.

[fordfrog]

This warrants a discussion with ffmpeg maintainers (who are out of reach for me probably), as they may not accept this change (Arch seems to be fine with it though).

Unless upstream want to take it, I don't think this is doable. We pride ourselves on being vanilla without gratuitious patching and changing API is not acceptable.

in case of this ffmpeg patch, it just adds one function (you can see the patch here). the same patch would be needed for dev-qt/qtwebengine and other chromium based packages, as illustrated by this bug - it was "resolved" by dropping system-ffmpeg use flag in this case. as @PF4Public noted, arch linux is fine with this patch. that does not guarantee anything on our side though, but still, this is a minor feature that can be masked for all users and those that want could unmask it and patch ffmpeg themselves.

fordfrog's suggestion of just doing everything the same, including development in this repo, and just copying stuff into ::gentoo for the stable channel seems reasonable, but at the very least would need fordfrog to help with reviewing and merging PRs, as we're already struggling with effort to get @Kangie's PRs in.

i'm aware of that and i'm fine with that.

[Kangie]

there is usually 30 days period after which a stabilization request is filed and stabilization team checks the package is really ready for being marked as stable. there might be issues related to the way how we package the app etc, so this is the standard process

While that's the standard process Chromium in particular moves very quickly and we're often updating and stablising versions in ::gentoo due to the CVEs in each upstream release.

In saying that I'd be more than happy to see more Chromium in ::gentoo. I don't have the time at the moment to give Chromium the love that the package deserves, but I am happy to help out with getting the package into the repository and see about a workflow where maybe we can both do less work overall!

[darkbasic]

Unless upstream want to take it, I don't think this is doable. We pride ourselves on being vanilla without gratuitious patching and changing API is not acceptable.

@thesamesam I would personally be much more interested in seeing electron into Gentoo. Gentoo's ebuild is basically a binary blob, which is basically against the philosophy of the distro. Also while it might work for x86 it's not an option on any other architecture.

[Kangie]

@thesamesam I would personally be much more interested in seeing electron into Gentoo. Gentoo's ebuild is basically a binary blob, which is basically against the philosophy of the distro. Also while it might work for x86 it's not an option on any other architecture.

This is way off-topic. Please file a bug (or update an existing bug) on Gentoo's Bugzilla.

The post you quoted is about making changes to ffmpeg for chromium and nothing else.