- User Since
- Jul 16 2017, 10:17 AM (109 w, 5 d)
Thu, Aug 22
Fri, Aug 16
Tue, Aug 13
Please file a _new_ issue instead: It might make good sense to use other addons, but that does not mean that the currently used addons are not working and therefore this issue is wrong to have "open".
Mon, Aug 5
No need for apology - your concern is appreciated even if it turns to be unfounded.
This sounds similar to issue T585.
Fri, Aug 2
Wed, Jul 31
Tue, Jul 30
Am looking into this, but not simple due to upstream changes requiring additional Python libraries packaged.
Jul 10 2019
yes, this is yet another area of this Mozilla product (unsurprisingly, really) linking to Mozxilla resources.
Jul 2 2019
Thanks for the followup. Feel free to post status updates here about the upstream progress :-)
Thanks, @rinigus !
@EchedeyLR Thanks for investigating. Please however report any concrete findings as separate issues.
@mak Please stop block chromium - it does not contain non-free code and is no longer unclear about licensing.
Jun 24 2019
Thanks for reporting.
Jun 21 2019
Since this bugreport may be used as inspiration for users wanting to work around the issue, I have adjusted the description to talk about adding file below /etc, because editing existing file below /lib is lost when package udev is updated.
Jun 20 2019
It should not be surprising that logfiles indicate that -1pureos2really60.7.1esr1 was rejected multiple times, because that is what I experienced and the reason I wrote "tried several times" in the description.
@mak: Failed again: "firefox-esr_60.7.0esr-1pureos4_source.changes is already known."
How do you mean the package was "indeed already known"? If you mean to say that you are certain that those releases had already been accepted preciously then what happened to them?
Jun 19 2019
Jun 13 2019
The code excluded in the Debian package is a separate upstream project added by upstream as a convenience code copy.
Jun 3 2019
It is not perfect but its features and its limitations are well known both to us and to our users.
Thanks for clarifying, @jeremiah.foster.
@jeremiah.foster you extended the description field of this issue to specifically list DuckDuckGo as bad.
May 20 2019
Removing myself as assignee of this issue: Seems done by myself accidentally, and in any case I am incapable of driving this issue.
Correction: This _is_ a freedom issue, not because it (optionally) uses nonfree (or rather closed-protocol) service but because (optionall, when configuring to use that protocol) it downloads nonfree software.
May 10 2019
Thanks for confirming. Enjoy :-)
Thanks for noticing, @Amgine.
May 8 2019
I agree that it seems the study gets installed onto the local machine - but not run: the fix was not applied.
May 7 2019
firefox-esr (a.k.a. PureBrowser) 60.6.2esr-1pureos1 was confirmed accepted 25 minuts ago.
For the "pull in the latest firefox-esr from Debian" part, it was prepared earlier today¹ and uploading (but failing and failing) now².
I am still not convinced that anything more severe than cosmetic was "going on": Please clarify how you come to the conclusion that Firefox Shield studies was installed and run.
May 6 2019
It is my understanding that PureBrowser is immune to the Normandy backdoor, because PureBrowser has removed the hidden system add-on "Application Update Service Helper" (along with all other hidden system add-ons).
Is PureBrowser the *only* Mozilla browser you run on that machine?
May 4 2019
You are right: An issue tracker is the wrong tool for writing or inquiring a how-to.
Apr 23 2019
@jeremiah.foster Please (not only update description but also) make a comment elaborating why you consider DuckDuckGo is really tracking users.
Apr 19 2019
Raising priority, since a package without security tracking from Debian for a year is bad!
Seems emacs25 was dropped a year ago from Debian but is still lingering in PureOS, and I guess then also blocking the more recently introduced emacs (without version in package name, currently containing version 26) to enter PureOS at all.
Apr 16 2019
Apr 14 2019
Rebuilding sure avoids some (possibly gazillions) edge cases. This issue is about something else, though:
Sorry, I don't follow what is so definite. Why do we not - by the exact same logic - "definitely" need to rebuild all the packages that we grab from testing?
Apr 13 2019
Apr 4 2019
Whoops, didn't mean to close this (just wanted to look for the exact terms used in there...)
This issue has a question as its title. Is the issue then "Resolved" when the question is answered? And should we tag it "Invalid" if multiple conflicting answers emerge?
Apr 2 2019
If foobar v5.0.1 is stable and foobar v6.0beta2 is unstable, then what is foobar v4.2? And what is foobar v6.0+git20190304?
Mar 28 2019
Great that it works now.
Please try install using aptitude - in case that reveal more/different details: sudo apt install aptitude and then sudo aptitude install openttd
Mar 27 2019
The error message hints that held packages may be the cause.
Seems this was reported upstream more than a year ago: https://bugs.debian.org/884372
Mar 24 2019
In other words: Feel free to reassign to me for now if you prefer
Ah, sorry - I was wondering why I had "missed" to file this issue sooner, and your remark now hints that there was a good reason.
No problem with processing delay: Had it been urgent then I would have shouted louder :-)
Mar 20 2019
@mak you wrote this in a related discussion (in a non-public chat where you gave permission to quote in public):
Laniakea can sync a specific list of packages from any suite into landing, however this is definitely not a smart idea on PureOS as it currently is. We did that mistake on Tanglu in the past. Since PureOS doesn't rebuild all packages synced from Debian, there might be subtle incompatibilities, or synced packages would just flat out not work due to dependency issues. Or the synced experimental packages would break other stuff if not rebuilt against them, GLib is a primary candidate here (but we also had DBus interface incompatibilities occasionally).
So, if we sync stuff from random suites, I would also opt for rebuilding all Debian packages for PureOS, which in turn would require us to do transitions like Debian does (which would mean people would have to monitor and do those).
Mar 18 2019
Scope of this issue now relaxed to include source-identical but rebuilt packages.
Whoops, sorry: I totally misread this issue: Clearly not that PureOS is too unstable.
I generally find that it is easier to handle issues when framed by describing the "issue" (i.e. the thing broken or missing) as the topic - rather than an open-ended question.
Mar 8 2019
Why do PureOS distribute gksu at all? It was dropped from Debian a year ago: https://tracker.debian.org/pkg/gksu
Mar 7 2019
Since you insist, @jeremiah.foster, on expanding/redefining the scope of this issue to be about switching *GENERALLY*, I cannot help and therefore unsubscribe from participation here:
Mar 6 2019
@jeremiah.foster are you asking to *generally* switch from tracking testing to track unstable (or experimental), or are you - like this issue was initially intended to be about - asking about singling out packages to be tracked exceptionally from unstable (or experimental), where packages otherwise generally continue to track testing?
Mar 4 2019
Mar 2 2019
@tbernard I suggest you repeat your question to ensure that the others tracking the original bug which this is a duplicate/mirror of hears it. You might also want to read the backlog, as they might have already answered your question ;-)