Thanks for sharing!

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"

Thanks for your information.

It's actually easy to identify which apps were installed, because I tested this issue with a default installation of all operating systems mentioned, the only extra package being installed was the Atom package itself (along with its dependencies).

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

I have not found any other application with this same issue in PureOS, which is why I created a bug report for the Atom text editor specifically. I thought it appropriate to put the bug here, because it only happens in PureOS (not in Debian Stretch, Debian Testing, Linux Mint, or Trisquel 7/8), so I think it must be specific to something unique to PureOS.

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.

What about this one as the "about" one?

We need the equivalent of https://code.puri.sm/pureos/firefox-esr/src/master/browser/branding/official/content/about.png.

Hi @james.rufer
Unfortunately, I can't reproduce this. I have successfully imported both of my keys (as well as singly) using the Enigmail setup wizard into PureOS's Thunderbird but cannot see this freeze, alas.
(Can you clarify exactly what import/export mechanism you are using? Enigmail offers a couple with very similar names.)

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

Hi @james.rufer
I can't seem to reproduce this. gdebi installs fine for me, and launches fine both from the Applications menu and from the command line. Can you clarify exactly how you are trying to run it? Note that gdebi-gtk is the command, not gdebi.

• lam—

Thanks for the update. So, this is quite a common problem that affects Chromium generally (Google it!) and, alas, has an almost infinite number of causes AFAICT.

I moved the config directory as you suggested and it seems to have fixed the problem. Thanks!

I have updated the file (same URL).

Regarding license: Please open Document properties, and fill out "Metadata" and "License".

Thanks! That SVG is usable as-is to generate all but one of the PNGs.

I don't understand which timeline you are talking about.

Yes @jonas.smedegaard I have an SVG version of the icon. You can get it here : https://pureos.net/downloads/icons/purebrowser-icon.svg

If we're using DuckDuckGo and want a stripped back user experience, I'd suggest the base URL of https://start.duckduckgo.com rather than https://duckduckgo.com

This one was uploaded *after* I reverted the previous changes. Now I can't do that anymore without a fake upload, since the PureOS version is newer than in Debian.

@jonas.smedegaard I would actually prefer that PureBrowser recommends the extensions we want to ship with it - it would make logical sense for the browser package to pull in the extensions we recommend, instead of the system's seed depending on those directly.
By having PureBrowser just recommend the package, users can still easily uninstall it later.

If you have an SVG image then I need that, yes.

Well, I am not sure to understand correctly. Do you need the SVG image of the icon with some kind of tag within the file as the license?

Thank you all, installing texlive-full works for me now!

This issue is believed fixed with the recent upgrade of PureBrowsr to version 52.5.0esr-1pureos1.

texlive-full in PureOS green is now 2017.20171128-1.

PureBrowser has been repackaged, based on a newer Firefox: Please test if this issue persist.

@mak I believe you are the one orchestrating what constitutes "default install of PureOS".

@mak I believe you are the one orchestrating what constitutes "default install of PureOS".

@mak I believe you are the one orchestrating what constitutes "default install of PureOS".

@mak I believe you are the one orchestrating what constitutes "default install of PureOS".

For the record, I do not personally agree with this issue (I don't use said addon myself): This issue is derived from T147 which in turn is derived from a request by @zlatan.todoric

Consider this issue to be about privacy (T110 is about nonfree services which duckduckgo is as well)

While it might be colateral, this issue is separate from issue T147 tracking the PureBrowser package restructuring.

As explained by Matthias on irc, package ban is source-specific: Banning Debian as source of firefox-esr continue to make sense and does not block upload of same-named firefox-esr ourselves.

Package purebrowser now (since release 52.5.0esr-1pureos1) depends on neither xul-ext-ublock-origin nor xul-ext-adblock-plus.

Package purebrowser used to depend on package xul-ext-ublock-origin (and xul-ext-adblock-plus too? See issue T108), but we better solver this independently from PureBrowser, to provide the freedom of opt-out to _not_ installing the plugin.

This issue was originally reported as part of issue T108 but separated: We better solver this independently from PureBrowser, to provide the freedom of opt-out to _not_ installing the plugin.

This issue was originally reported as T108 but separated: We better solver this independently from PureBrowser, to provide the freedom of opt-out to _not_ installing the plugin.

Inclusion of Privacy Badger now tracked as separate issue T271.