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.

Thanks for reporting.

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.

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?

The code excluded in the Debian package is a separate upstream project added by upstream as a convenience code copy.

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.

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.

Thanks for confirming. Enjoy :-)

Thanks for noticing, @Amgine.

I agree that it seems the study gets installed onto the local machine - but not run: the fix was not applied.

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.

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?

You are right: An issue tracker is the wrong tool for writing or inquiring a how-to.

@jeremiah.foster Please (not only update description but also) make a comment elaborating why you consider DuckDuckGo is really tracking users.

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.

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?

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?

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?

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

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

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 :-)

@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).

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.

Why do PureOS distribute gksu at all? It was dropped from Debian a year ago: https://tracker.debian.org/pkg/gksu

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:

@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?

@mak yet another friendly nudge...

@mak yet another friendly nudge...

@mak yet another friendly nudge...

@mak yet another friendly nudge...

@mak yet another friendly nudge...

@mak yet another friendly nudge...

@mak yet another friendly nudge...

@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 ;-)

That is quite likely part of "Activity Stream" which has been removed in PureBrowser, compared to Firefox ESR: See T534

From a user experience POV it would be better to not be bothered like this.

What we do different with Firefox is _remove_ some functionality that Mozilla ships by default and then also force-include some WebExtensions which Debian ship as well but do offer for their users to freely decide if they want part of their Firefox experience.

Thanks for those new details.

It was a wild guess at what might cause the issue at the _host_ side which is not PureOS.

@jeremiah.foster It does not make sense to me why/how this bug is closed.

For the record (as I understand time's up for your concrete case), use of Logical Volume Management (LVM) can provide a user experience of a single "virtual" partition, stitched together from multiple underlying physical "volume" partitions.

well, in my splitting-hairs mode it is factually alarming: It set off an alarm, of the cenventional blinkenlight type.

I believe it is only the install routines for PureOS that has problems with EFI, the installed PureOS works fine with EFI.