[ISSUE] [feedback request] drop icecat

[ISSUE] [feedback request] drop icecat

[q66]

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

New issue by q66 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731

Description:
Void has previously made it policy to avoid introducing random forks of major browsers. Despite that, we still have `icecat` in the repos, which seems to me to be pretty much just `firefox-esr` with altered branding and some custom extensions and changed settings. It is so close to just `firefox-esr` that the project no longer bothers to create their own release tarballs, so the `icecat` template in Void fully relies on custom tarballs created by @pullmoll, despite it usually also being policy that we package software from official release archives except in special cases.

So the question is, are those changes it brings worthwhile enough to warrant an entire new firefox build (this one even more annoyingly long than the ordinary one, since it has to generate the localization packages from scratch, which takes a significant chunk of the overall time)? And if those changes are in fact worthwhile, why can't they be done externally to our standard firefox build, in form of config tweaks and custom installable extensions?

This whole thing seems rather puzzling to me. One thing I heard raised as an advantage is that icecat has its own home directory path, so it doesn't conflict with mainline non-esr firefox, but that sounds more like an excuse than anything else to me.

@void-linux/pkg-committers 

Re: [feedback request] drop icecat

[Vaelatern]

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

New comment by Vaelatern on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-755911145

Comment:
Should it be proposed today, icecat would not make it in.

We also don't remove old packages without a stricter set of requirements than those we use for accepting packages. I personally have little issue with dropping it, but it might be weird for Void Linux to decide to randomly drop an existing package. Maybe mark it Restricted?

Re: [feedback request] drop icecat

[the-maldridge]

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

New comment by the-maldridge on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-755912176

Comment:
Historically a seperate icecat made sense, but I no longer see the relevance of it.  It sounds like the upstream is dead from a release standpoint, which makes it a hard argument to continue unless pullmoll is effectively now the upstream.

Re: [feedback request] drop icecat

[pullmoll]

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

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-755922182

Comment:
Icecat is a little more than just rebranding firefox-esr AFAICT: LibeJS, privacy enhancing configuration changes, removal of non-free or user rights restricting extensions (DRM, EME), removal of telemetry. See https://directory.fsf.org/wiki/Gnuzilla

The current situation is unsatisfying because since 78.x there are no official tarballs but just the `makeicecat` script suite which applies patches and creates the tarball. I'd love to avoid having to build the tarballs, yet I don't know when gnuzilla will resume publishing them again.

If you want to remove icecat, please do. Just don't count on me for explaining to anyone why it was removed.

Re: [feedback request] drop icecat

[pullmoll]

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

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-755922182

Comment:
Icecat is a little more than just rebranding firefox-esr AFAICT: LibreJS, privacy enhancing configuration changes, removal of non-free or user rights restricting extensions (DRM, EME), removal of telemetry. See https://directory.fsf.org/wiki/Gnuzilla

The current situation is unsatisfying because since 78.x there are no official tarballs but just the `makeicecat` script suite which applies patches and creates the tarball. I'd love to avoid having to build the tarballs, yet I don't know when gnuzilla will resume publishing them again.

If you want to remove icecat, please do. Just don't count on me for explaining to anyone why it was removed.

Re: [feedback request] drop icecat

[the-maldridge]

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

New comment by the-maldridge on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-755923160

Comment:
I think in many ways its just a curiosity.  A link to the above comment would add a lot of context to why this template is being carried.  Would it be practical to implement the template in such a way that it pulls the original tarball and runs `mkicecat` inside the `do_patch` phase?

Re: [feedback request] drop icecat

[pullmoll]

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

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-755924072

Comment:
Well, `mkicecat` itself downloads the firefox-esr tarball and verifies the sha256sum and signature.
Then it takes a very long time to patch the sources - on our builders that would probably be hours.
Doing this for every target in the do_patch() would slow it all down by a factor of 2-3 AFAICT.

Re: [feedback request] drop icecat

[the-maldridge]

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

New comment by the-maldridge on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-755924485

Comment:
I see.  Lets not do that then.

Re: [feedback request] drop icecat

[ericonr]

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

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-756129096

Comment:
The issue would be leaving icecat users with an older browser; we can't make it a meta package that depends on firefox-esr, because that'd block them from accessing their profile, so the only solution I can think of is leaving it stale and removing with `removed-packages`.

Re: [feedback request] drop icecat

[q66]

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

New comment by q66 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-756133428

Comment:
well, I wouldn't just go and remove it; but it should definitely be investigated whether the custom extensions and settings can be added on top of firefox, and if they can, then there is no actual reason to keep it around

Re: [feedback request] drop icecat

[uzr123x]

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

New comment by uzr123x on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-756339306

Comment:
remove it and add SeaMonkey instead c: At least it's not merely 'rebranded' Firefox with a couple of addons, a new logo and some tweaked settings.

Re: [feedback request] drop icecat

[tibequadorian]

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

New comment by tibequadorian on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-757564920

Comment:
just wanna say that I'm glad that icecat is in the repository but I understand the argument

Re: [feedback request] drop icecat

[tibequadorian]

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

New comment by tibequadorian on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-757564920

Comment:
just wanna say I'm glad that icecat is in the repository but I understand the argument

Re: [feedback request] drop icecat

[travankor]

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

New comment by travankor on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-757769854

Comment:
can do what #27419 suggests -- have a package that applies some better defaults to ff

Re: [feedback request] drop icecat

[the-maldridge]

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

New comment by the-maldridge on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-757786141

Comment:
The decision for now seems clear to retain the package, thank you all for comments.

Re: [ISSUE] [CLOSED] [feedback request] drop icecat

[the-maldridge]

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

Closed issue by q66 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731

Description:
Void has previously made it policy to avoid introducing random forks of major browsers. Despite that, we still have `icecat` in the repos, which seems to me to be pretty much just `firefox-esr` with altered branding and some custom extensions and changed settings. It is so close to just `firefox-esr` that the project no longer bothers to create their own release tarballs, so the `icecat` template in Void fully relies on custom tarballs created by @pullmoll, despite it usually also being policy that we package software from official release archives except in special cases.

So the question is, are those changes it brings worthwhile enough to warrant an entire new firefox build (this one even more annoyingly long than the ordinary one, since it has to generate the localization packages from scratch, which takes a significant chunk of the overall time)? And if those changes are in fact worthwhile, why can't they be done externally to our standard firefox build, in form of config tweaks and custom installable extensions?

This whole thing seems rather puzzling to me. One thing I heard raised as an advantage is that icecat has its own home directory path, so it doesn't conflict with mainline non-esr firefox, but that sounds more like an excuse than anything else to me.

@void-linux/pkg-committers 

Re: [feedback request] drop icecat

[pullmoll]

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

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-757797117

Comment:
OT: Could we use a powerful build server? I'm willing to sponsor an e.g. [Hetzner AX161](https://www.hetzner.com/de/dedicated-rootserver/ax161) with 1TB SSD (?) and 2x 10TB HDD for two years. Needs someone to do the setup and maintenance, though, as I'm not a good admin.

Re: [feedback request] drop icecat

[pullmoll]

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

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-757797117

Comment:
OT: Could we use a powerful build server or even master? I'm willing to sponsor an e.g. [Hetzner AX161](https://www.hetzner.com/de/dedicated-rootserver/ax161) with 1TB SSD (?) and 2x 10TB HDD for two years. Needs someone to do the setup and maintenance, though, as I'm not a good admin.

Re: [feedback request] drop icecat

[the-maldridge]

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

New comment by the-maldridge on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-757800163

Comment:
Sure, lets discuss over in either the infrastructure repo or in IRC.  Pick your preferred venue; I'd like to move the musl build box to the EU so we aren't taking packages transatlantic during the build cycle.

Re: [feedback request] drop icecat

[q66]

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

New comment by q66 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-757935082

Comment:
I don't see how the decision is "clear". Also I want to keep this open so that it's not forgotten and we don't stay with the status quo forever

E.g. regarding LibreJS: looks like you can just install that into firefox as an ordinary addon from the usual place 

Re: [feedback request] drop icecat

[uber97]

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

New comment by uber97 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-762735321

Comment:
I don't know if that's an idea Void maintainers would agree, but I'm thinking about shipping [LibreWolf](https://librewolf-community.gitlab.io/) as a replacement for IceCat.

Re: [feedback request] drop icecat

[the-maldridge]

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

New comment by the-maldridge on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-762736036

Comment:
We would drop without replacement @uber97.  The intent and perhaps not clearly communicated goal here is to ship fewer forks of the major browsers.

Re: [feedback request] drop icecat

[tarkov2213]

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

New comment by tarkov2213 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-767963588

Comment:
Is there a reason why the alternative browsers aren't at least introduced as restricted so that users that want them can choose to xbps-src them themselves? The builds don't appear to be trivial even when taking existing templates and switching things around - that is to say it often fails.

Re: [feedback request] drop icecat

[the-maldridge]

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

New comment by the-maldridge on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-767964565

Comment:
@tarkov2213 restricted is still governed by the quality bar for package inclusion, which among other things disallows packages that just rot in the repos.

Re: [feedback request] drop icecat

[tarkov2213]

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

New comment by tarkov2213 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-767984641

Comment:
> @tarkov2213 restricted is still governed by the quality bar for package inclusion, which among other things disallows packages that just rot in the repos.

But the stated reason for these packages (ungoogled-chromium, brave, librewolf etc) not being included is not their quality but compile time on the build server. If users requested them, they will be used. So how will they rot?

Re: [feedback request] drop icecat

[tarkov2213]

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

New comment by tarkov2213 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-767984641

Comment:
> @tarkov2213 restricted is still governed by the quality bar for package inclusion, which among other things disallows packages that just rot in the repos.

But the stated reason for these packages (ungoogled-chromium, brave, librewolf etc) not being included is not their quality but compile time on the build server. If users requested them, they will be used. So how will they rot? Google chrome is there and it's not even source, which arguably is of much greater concern than any of these other packages (dependency breakage, security, etc).

Re: [feedback request] drop icecat

[tarkov2213]

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

New comment by tarkov2213 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-767984641

Comment:
> @tarkov2213 restricted is still governed by the quality bar for package inclusion, which among other things disallows packages that just rot in the repos.

But the stated reason for these packages (ungoogled-chromium, brave, librewolf etc) not being included is not their quality but compile time on the build server. If users requested them, they will be used. So how will they rot? Google chrome is there and it's not even source, which arguably is of much greater concern than any of these other packages (dependency breakage, security/inauditability, etc).

Re: [feedback request] drop icecat

[ahesford]

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

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-767998895

Comment:
"Restricted" means Void is, well, restricted from distributing the package contents. It is not a mechanism to provide templates we just don't care to build.

A key reason for not allowing other browsers is their excessive build time. That doesn't mean it's the only reason. Restricted packages tend to rot faster than regular packages because the tooling that ensures consistency of the repository is (necessarily) unaware of restricted packages, so we can't track potential breakage when we update other packages.

Re: [feedback request] drop icecat

[tarkov2213]

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

New comment by tarkov2213 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-768011986

Comment:
@ahesford fair enough, what about introducing another category for "templates we just don't care to build"? Because as things stand there really is no other choice for many of these packages other than to just hope they provide binaries and those binaries work. Even a sporadically maintained template would be better and after they are made updates would often consist of nothing more than changing a few numbers.

Re: [feedback request] drop icecat

[tarkov2213]

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

New comment by tarkov2213 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-768011986

Comment:
@ahesford fair enough, what about introducing another category for "templates we just don't care to build"? Because as things stand there really is no other choice for many of these packages other than to just hope they provide binaries and those binaries work. Even a sporadically maintained source build template would be better and after they are made updates would often consist of nothing more than changing a few numbers.

Re: [feedback request] drop icecat

[ahesford]

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

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-768017150

Comment:
That's called https://github.com/tarkov2213/void-packages

Void doesn't offer a user repository like Arch, but nothing stops you or anybody else from forking the repo and maintaining your own templates. The official repository bears the burden of maintenance. We strive (imperfectly) to keep everything well maintained, and providing official templates that we don't care enough even to build would take Void further from the goal. 

Re: [feedback request] drop icecat

[tibequadorian]

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

New comment by tibequadorian on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-768269733

Comment:
I might be wrong but void-packages is not really built for that. I found it very cumbersome as a user to handle templates from different forks, like manually copying over the folder containing the template and having no easy way of updating them automatically...

Re: [feedback request] drop icecat

[tibequadorian]

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

New comment by tibequadorian on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-768269733

Comment:
I might be wrong but void-packages is not really built for that. I found it very cumbersome as a user to handle templates from different forks, like manually copying over the folder containing the template and having no easy way of updating them...

Re: [feedback request] drop icecat

[Gottox]

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

New comment by Gottox on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-768277573

Comment:
We had the browser discussion multiple times and I still think, that it is crucial for a browser to be well maintained. A task that no one but the original developers managed to do over a longer period of time. I'm all in for the removal.

Re: [feedback request] drop icecat

[ericonr]

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

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-768461206

Comment:
@pullmoll ok to close?

Re: [ISSUE] [CLOSED] [feedback request] drop icecat

[pullmoll]

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

Closed issue by q66 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731

Description:
Void has previously made it policy to avoid introducing random forks of major browsers. Despite that, we still have `icecat` in the repos, which seems to me to be pretty much just `firefox-esr` with altered branding and some custom extensions and changed settings. It is so close to just `firefox-esr` that the project no longer bothers to create their own release tarballs, so the `icecat` template in Void fully relies on custom tarballs created by @pullmoll, despite it usually also being policy that we package software from official release archives except in special cases.

So the question is, are those changes it brings worthwhile enough to warrant an entire new firefox build (this one even more annoyingly long than the ordinary one, since it has to generate the localization packages from scratch, which takes a significant chunk of the overall time)? And if those changes are in fact worthwhile, why can't they be done externally to our standard firefox build, in form of config tweaks and custom installable extensions?

This whole thing seems rather puzzling to me. One thing I heard raised as an advantage is that icecat has its own home directory path, so it doesn't conflict with mainline non-esr firefox, but that sounds more like an excuse than anything else to me.

@void-linux/pkg-committers 

Re: [feedback request] drop icecat

[q66]

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

New comment by q66 on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-768489659

Comment:
in short to medium term we should perhaps look into providing an extra package to disable telemetry and so in default prefs, should be a sufficient alternative

Re: [feedback request] drop icecat

[Raffadiely]

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

New comment by Raffadiely on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-771035215

Comment:
I use Icecat as a Unmozillaed Firefox, akin to the Ungoogled Chromium project. I'm sad to see it removed from Void, though I understand the reasons as to why.

Like q66, if I am to use Firefox, I would appreciate some kind of privacy patching package to be present in the repos (though I don't have the skill to create and maintain one myself).

In the meantime, and for anyone who finds this issue when they see Icecat in removed-packages, some good privacy tools for Firefox include [Firefox Profilemaker](https://ffprofile.com/) or [the arkenfox user.js](https://github.com/arkenfox/user.js)

Re: [feedback request] drop icecat

[Raffadiely]

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

New comment by Raffadiely on void-packages repository

https://github.com/void-linux/void-packages/issues/27731#issuecomment-771035215

Comment:
I use Icecat as a Unmozillaed Firefox, akin to the Ungoogled Chromium project. I'm sad to see it removed from Void, though I understand the reasons as to why.

Like q66, if I am to use Firefox, I would appreciate some kind of privacy patching package to be present in the repos (though I don't have the skill to create and maintain one myself).

In the meantime, and for anyone who finds this issue when they see Icecat in removed-packages, some good privacy tools for Firefox include [Firefox Profilemaker](https://ffprofile.com/) or [the arkenfox user.js](https://github.com/arkenfox/user.js).