This issue is bogus - even if package is reintroduced into PureOS: libxnvctrl does _not_ need nor promote non-free software (see T64).

This issue is bogus: libxnvctrl does _not_ need nor promote free software (see T64).

This issue is bogus: libxnvctrl does _not_ need nor promote free software (see T64).

This issue is bogus: libxnvctrl does _not_ need nor promote free software (see T64).

This issue is bogus: libxnvctrl does _not_ need nor promote free software (see T64).

I have come to same conclusion as you, @mak, that this is no Freedom issue, and too painful without any real gain to try solve.

That's your call.

I see several approaches:

Seems directly tied to bootstrapping tools in the hands of Matthias.

@heather.ellsworth I took the liberty of retitling "your" issue here to describe the issue to be addressed.

Fixed upstream in Debian (see T599).

In T202#11747, @jeremiah.foster wrote:

I wonder if we want to have an acceptance criteria for this issue since while it is "closed" it is not "solved" perhaps.

This is T202 - merging into this newer one (instead of opposite) because this one had more details - except for the exact "error message" of the wording of the button when (mis)detected as not being _exactly_ Firefox.

I can suggest to create an issue for each addon, both to track their relationsips (e.g. if an addon like TOS;DR relates to _both_ privacy and freedom), and to track their resolution (i.e. packaging in Debian).

I suspect (but haven't looked closed) that some of the listed addons more appropriately belong in a new separate issue "PureOS is not freedom-governing enough by default".

I took the liberty of changing the title to describe the issue to be addressed here.

In T595#11754, @jeremiah.foster wrote:

Thank you @mladen.pejakovic. From what I can see, this essentially solves the issue no? I think we should close this issue.

Ah, thanks for the clarification. Makes sense to me now :-)

which menu are you talking about? Something inside the PureBrowser window, something part of the window containing PureBrowser, or something in some menu elsewhere (e.g. provided by your desktop environment)?

@sean.obrien you mention "menu items that go nowhere".

Indeed - package has already entered landing so should migrate to green in few days: http://software.pureos.net/search_pkg?term=pyotherside

@sean.obrien I now clarified scopes of issues T110 and T156, and here.

This issue is now about PureBrowser linking to DuckDuckGo non-free JavaScript.

Even if this was meant (also) as a duplicate of T110, we can reuse it to track (only) the related issue of avoiding Javascript not Free licensed.

Sorry for you that your hardware cannot work with Free software.

Fratal no longer depend indirectly on gnulib.

Thank you for clarifying the nature of this issue. Title and priority adjusted accordingly.

PureOS avoid code which Debian or the GNU project considers nonfree - despite others (inlcuding kernel developers) having different opinions regarding licensing and the need for sources of code/data/blobs.

PureOS does not contain the web pages of duckduckgo.com but do indeed currently link to that website.

If you change your system to be a mixture of PureOS and other sources, then your system is no longer a PureOS system.

Please mention which versions of the packages pulseaudio and libasound2-plugins is installed on your system.

Please mention which versions of the packages pulseaudio and libasound2-plugins is installed on your system.

Thanks for reporting this issue!

Revert to track only freedom issue (not the related issue of it not being a freedom issue after all).

Revert to track only freedom issue (not the related issue of it not being a freedom issue after all).

From Matrix discussions, this might affect Bluetooth as well (mentioning also to improve serch terms)

s/removed/reset/

@mak Do I understand correctly that clamav can now be removed without the need for a dummy package?

more info at https://bugs.debian.org/876087 and T235.

I believe I understand you opinion on this. I then disagree, however.

Is it in your opinion more important to fix immediately (i.e. no time to wait for PureOS, we must hand over the keys to the castle to upstream) bugs in Tor Browser, or do you find it equally important that we (as they become available) enable mechanisms for the Linux developers and GNOME developers and any other upstreams to address 0-days in their code?

Agreed, torbrowser-launcher has been and still is in debian (just not main).
However, since that package bypasses APT, Debian has effectively passed on the maintenance of Tor Browser itself (not the bypassing script, but that it less relevant) to upstream, so how responsive the Debian security team has been regarding torbrowser-lanucher is irrelevant to 0-days of Tor Browser itself.

(reminder: Feel free to disagree - I don't state universal facts here, just am inconsistent in adding "in my opinion"...)

In-browser mechanisms to bypass APT is severe bugs that should be fixed by patching them away, as is currently done for PureBrowser.

0-day issues with Tor Browser should be handled exactly same as 0-day issues for all parts of PureOS: By PureOS developers issuing a bugfix.

I believe Tor Browser (previously named Tor Browser Bundle a.k.k. TBB) itself was never packaged for Debian, nor released with PureOS.

In my opinion, this issue should be solved by packaging Tor Browser for Debian main.

...but the very issue you are raising here, if I understand you correctly, is that things like Electron apps and Tor Browser are - in your opinion - reasons to relax that "whenever possible" part. Right?

Others than me in Purism/PureOS are happy about Flatpack - doesn't that provide the needed sidechannel for injecting these popular tools?

A bit of some history...

I don't mean to kill the conversation here. Just want to keep separate concrete issues from "meta issues". I will take the liberty of relabeling this one to perhaps better fit what we are discussing here...

Regarding what we can and cannot do according to FSF guidelines: Are you asking what the guidelines says, or are you asking how much we can bend the rules before our relations with them snap?

Not sure what you mean by "replicate everything in-house".

To clarify: You do _not_ need to search through and locate previous issues. Nice if you do, but perfectly fine if you don't have time for that. File new issues and leave it to us to correlate and maybe merge with existing ones. :-)

I agree none of what you presented here _is_ T247 - only _related_ to it.

This covers several issues, making it difficult to track.