I meant T1024.

Strictly speaking, this issue is about Maintainer field. T1023 was about Vcs-* fields.

Concretetely, I propose to replace this:

The Debian bugtracker has a similar task of tracking issues potentially tied to multiple distro releases, and handles that like g).

Taking T1027 as an example, I see several options here:
a) we track code project source: issue is done when solved at the code source of what is being packaged
b) we track code project release: issue is done when solved at the code source of what is being packaged and released (e.g. as tarball or git tag)
c) we track packaging project source: issue is done when solved at the packaging source
d) we track packaging project release: issue is done when solved at the packaging source and released (i.e. git tag and pushed to any queue)
e) we track any distribution: issue is done when package is available in any distro release (e.g. landing)
f) we track development distribution: issue is done when package is available in testing distro release (i.e. currently byzantium)
g) we track all distributions: issue is done when package is available in all supported distro releases (i.e. currently amber and byzantium)
h) we require explicitly defined scope: issue can only be done when clarified in issue itself where it is considered done.

@jeremiah.foster I think this issue is making good progress but still not resolved: Packaging Overview now properly covers requirement to add maintainer address, but lack the detail of preserving older Maintainer field.

It is now 13 days without migration - seems from https://master.pureos.net/migrations/excuse/6e70e037-1095-4e56-acae-4e854767fb5b that it "just" needs to be built on arm64.

Thanks, @alexander.mikhaylenko, the pending changes look good to me.

hmm - let's try see if status "incomplete" is something similar to "pending" - i.e. appears as open but distinct from "Normal"...

...and thanks for working towards solving this issue.

This issue tracker tracks development of packages, whereas https://source.puri.sm/ tracks development of code projects (often used as basis for packages).

The (supported) way to install Kodi on PureOS is to use the package which is part of PureOS, *not* use external packages from Ubuntu or elsewhere.

This issue should be fixed since release 2:19.0+dfsg1-1pureos1 of kodi, which should appear in Debian Byzantium within a week.

The Ubuntu issue referenced in that changelog section is this: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1918112

apt 2.2.2 arrived in Debian testing now (so should soon enter PureOS landing) might fix this - judging from its changelog: https://tracker.debian.org/media/packages/a/apt/changelog-2.2.2

wrong issue tracker - moved to https://source.puri.sm/Purism/docs.puri.sm/-/issues/38

pipx is a technical tool, not intended for regular users. It was packaged for Debian as it was requested for the _administration_ of Librem One services but explicitly *not* for general use.

as previously noted, this is a non-issue: no non-free package is suggested because the suggested package is not registered in apt so it is neither free nor non-free, it is instead nonexistent.

as previously noted, this is a non-issue: no non-free package is suggested because the suggested package is not registered in apt so it is neither free nor non-free, it is instead nonexistent.

as previously noted, this is a non-issue since the package cannot really suggest something that does not exist as a package registered with apt.

I have tested and can confirm that the use of suffix purge works to drop local fork:
https://lists.puri.sm/pipermail/pureos-changes/2021-March/001152.html shows the packages I uploaded, and https://software.pureos.net/search_pkg?term=zpb shows (at the time of writing this) that landing now contains the package from Debian.

Looks good.

Sorry to reopen, but I think the Guidelines are currently in a confusingly odd state:

Thanks for a swift resolution.

Excellent!

unp does not suggest a non-free package, only a non-existent one.

What exactly was tested 1000 times? some apt tool using an up-to-date libapt, or something more low-level?

https://serverfault.com/a/950568 mentions intermittent OCSP failures tied to IPv6.

https://stackoverflow.com/a/60243923 mentions how to disable OCSP for apt:

touch /etc/apt/apt.conf.d/99verify-peer.conf \
&& echo >>/etc/apt/apt.conf.d/99verify-peer.conf "Acquire { https::Verify-Peer false }"

maybe relevant to your research:
curl -O https://repo.pureos.net/pureos/dists/amber/main/source/Sources.xz works fine,
but curl -O --cert-status https://repo.pureos.net/pureos/dists/amber/main/source/Sources.xz fails:

curl: (91) No OCSP response received

@jeremiah.foster: please don't discuss [multiple issues] issues directly, but instead file a separate issue report for the part you have input on and discuss it there.

This issue is not about what is acceptable for people hired by or representing Purism to do.

I am unaware of any issues with Firefox ESR violating the FSF Free System Distribution Guidelines.
We are aware of a some issues that might violate FSDG, and we are examining each of those individually.

I am unaware of any issues with Chromium violating the FSF Free System Distribution Guidelines.

Thanks again. You can do that now at T992.

thanks for your input, @francois - but please wait until this multi-issue has been broken into parts before contributing further, because a) it is too difficult to discuss multiple issues at once in this interface, and b) it is not possible to reassign comments to other more narrow-scoped issue reports once made.

I reported this issue on my own (not driven by reports of others but from my prior knowledge in maintaining PureBrowser and therefore pretty exactly knowing how they differ).

I also recommend to subscribe to https://wiki.debian.org/Derivatives/CensusTemplate (hint: that page was updated today)

@jeremiah.foster as an initial action, I recommend that you subscribe to the wiki page, to get notified when others edit it - in case you disagree or appreciate learning from it.

oh, silly me: pantalaimon was never derived, so this is a non-issue.