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.

This issue was fixed since 52.6.0esr-2pureos1.

xul-ext-ublock-origin now recommended by the metapackages pureos-gnome and pureos-plasma.

xul-ext-https-everywhere now recommended by the metapackages pureos-gnome and pureos-plasma.

Either povray 1:3.7.0.4-2pureos1 went through NEW when I uploaded it on November 27 - three days _before_ your changes, or in went through NEW caused by your interventions.

Reopening but lowering to low priority: Package is currently fixed but likely to be dropped (see T330) and may then reappear and if so need fix reapplied.

Thanks a lot. Also for checking the 52.6 release!

Please mention the version of PureBrowser that you do not experience the issue.

Seems they do security tightening - not freedom tightening. Mentioning in case others (like me) misunderstood the description of this bug regarding being "closer to our philosophy".

Your browser-about.svg looks good. And with embedded IDs for globe and appname. Thanks!

This issue is flagged as "invalid" but not "closed for good".

PureBrowser is a quite close cousin of the particular Mozilla techonlogy called "Firefox".

This is not a bug in PureBrowser, but instead in that specific website.

This issue does not in itself harm freedom.

I believe - since this was moved from T299 - that this issue is about version 52.5.0esr-1pureos2 of PureBrowser.

Thanks for reporting!

Thanks for reporting these things.

Thanks for the screenshot.

apparently green does not yet include PureBrowser 52.5.0esr-1pureos1 - or mysteriously reverted to include the older version again.

apparently something blocks http://repo.pureos.net/pureos/pool/main/f/firefox-esr/ from entering green.

I created this task and you are mistaken: This is a "default in PureOS" task.

Hi QiZhi,

Assigning to you, @chris.lamb since you did the previous packaging work, and you use a different packaging style regarding git.

Based on francois' findings this seems to be an issue with Thinderbird, not PureBrowser.

Possibly this issue is bogus: When _switching_ from on to off it makes sense to make one final "leak" to request deletion of previously collected "leaks".

This issue is about the choice of search _engine_ - i.e. where requests typed into the search field end when hitting return.

Thanks for sharing!

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

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.

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.

Thanks for your information.

Thanks for (vaguely) hinting at what to look for in the screenshot. That is helpful.

ah, sorry - forgot to address your last remark:

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

The Atom Text Editor is not part of PureOS (nor Debian) so it would be most helpful if you could try locate some other tool that is supported by PureOS which has same distortions, so that we can replicate within the constraints of the system.