@mak Please block pipx from entering PureOS.

Wanted to bump this and check on it, thank you.

Since this was just mentioned again, I need feedback here... Go, or no go?
/me is for dropping it (at least temporarily).

This issue is solved since release 52.9.0esr-1pureos3, uploaded to landing today July 8th.

This T299 is now a meta-issue tracking the various ways that Mozilla addons service is getting promoted, and the main issue of the integrated addons support using Mozilla by default is now tracked at T305.

@d3vid The promotion of Mozilla addons service via Home screen is now tracked in separate issue T532.

@james.rufer yes, I did not mean to imply that this issue is not still open (the status in this very issue tracker is "open"). I only meant to ensure that if you had some additional information, that I then did in fact understand what that was.

Tested PureBrowser 52.9.0 with a fresh profile per https://tracker.pureos.net/T524

If you go to the hamburger menu and then add ons, you'll see the attached picture. In the past this was directed to a FSF add on page. After loading up the most recent build on a test machine without Firefox installed, the normal Firefox add-ons page is shown within PureBrowser. So the original issue remains despite my being incorrect as to the cause.

What URL(s) are you talking about?

If Firefox is also installed on the system, the PureBrowser FSF add-ons pages becomes the normal Firefox add-ons page instead.

This issue is about following requirements defined by the GNU DFSG. Bug description is now updated to include relevant quotes from GNU FSDG.

Also, every one of these package managers will not download non-free stuff behind the user's back. Like APT itself or a webbrowser, it will download things only if the users has directly requested that.

This is impossible, as pretty much all of GNOME, systemd, Xorg depends on Meson, and no Rust code can be built without cargo properly at the moment.

@jonas.smedegaard We deliberately added TorBrowser this way when creating PureOS back in the day. I never liked this at all, so personally I would like to remove the package, but I am not sure if we should do that, because the decision to have it that way was done on purpose.
@zlatan.todoric should the Tor Browser package be dropped from PureOS?

Please drop our fork of torbrowser-launcher: It violates GNU FSDG in that we lack control over what code ends on our users' systems.

Checking reverse dependencies...
# Broken Build-Depends:
pinto: cpanminus (>= 1.6916)

Dropping pinto as well.

Ok, I see what you mean!

We might get assurance from Tor Project. That does not, however, change the fact that we rely on a third-party for governing our rules, which I find problematic.

Indeed I confused the terms. Thanks for spotting - corrected now.

Or can we get some kind of assurance from the Tor Project about the continued freedom of the Browser Bundle?

I think you mean "torbrowser-launcher" above?

I suspect the Debian-but-released-only-in-contrib package was done that way due to the slow release cycle of Debian and the need for potentially quick update of the code. If that is the case, then a solution (other than simply giving up and kicking out torbrowser-bundle from PureOS) would be to replace with new package torbrowser - which could be maintained in Debian but there flagged as unreleasable similar to how other fast-moving code like Bitcoin is handled.

pip already came up with a decision. see the link above.

Again I see that you are not able to read.

You continue to discuss matters I have explicitly told you is outside the scope of this issue.

I guess you are not able to read.
Every single native packager for any single scripting language or other package system does allow installation of nonfree packages according to your terms, and would be thus as such banned from PureOS. Many of them already agreed to add a license meta field to their databases. So they are not hostile. You are the one who started the hostility against them.

I agree with you that (to the best of my knowledge) cpanm has no way of knowing the licensing of a CPAN module, and therefore cannot be instructed (by default or patched specifically for PureOS) to consider only modules that fits the licensing regime imposed on PureOS. This is the reason I see no other solution than to avoid cpanm in PureOS.

Uhm, it seems you are reading something between the lines here that I did not write.

So why are wanting to ban cpanm, and not the official client cpan out of the blue? You are acting completely irresponsible.

Yes, it makes good sense to report issues upstream - but only sometimes not always, and not as a prerequisite for filing issues here (if that is what you mean by "at least").

I don't understand all details of what you write, so will comment only on the parts I understand.

"A free system distribution must not steer users towards obtaining any nonfree information for practical use, or encourage them to do so. The system should have no repositories for nonfree software and no specific recipes for installation of particular nonfree programs. Nor should the distribution refer to third-party repositories that are not committed to only including free software; even if they only have free software today, that may not be true tomorrow. Programs in the system should not suggest installing nonfree plugins, documentation, and so on"

ah, sorry - forgot to address your last remark:

Yes, freedoms are ridiculous, depending on point of view.

This is ridiculous. So you want to exclude wget or chromium also, because it permits downloading nonfree code?