if already available in both releases we currently care about, I guess this is done.

Thanks for these suggestions.

purple-carbons is depended on by librem5-gnome-phone
purple-xmpp-carbons is recommended by chatty.

Seems this was addressed in source package pureos-meta on November 18th 2020.

Status update:

• squeekboard 1.11.1 in amber is still missing Vcs-* hints
• squeekboard 1.13.0-1pureos1 in byzantium is good

If you are interested, then I do have suggestions on how to try keep both qualities small - i.e. semi-automated routines - but they evolve around a core principle of treating the parent source (Debian) as the primary and PureOS getting applied on top.

I'd be more than interested ;)

What i'm after is that the changelog content is not related to how the package is prepared. There's tools to aid certain workflows but for d/changelog itself doesn't know anything about that. (what you describe sounds more like frustration about tool failing).

I have found that doing git merge <debian tag> on top of an already forked and deviated package leads to a package history which interleaves parent and fork-specific changes, which I have not found a way to automatically produce a (to me) comprehensible changelog from.

See also https://source.puri.sm/-/snippets/1165 which contains above script + my notes on surrounding tasks that I have so far been unable to automate, because I have so far found to it too variable across packages.

I am not fluent in Gitlab, but for the local repo part, I use this:

#!/bin/sh

I disagree that we should imply that meshed history is a good practice because I think it is incomprehensible to read a meshed history: It lead to my coming up with the "rebasing" strategy b) referenced in this issue report, and later lead me to file T1048 which triggered the creation of this issue report.

We need to find a balance of being comprehensible for you and workable for developers (most of which just merge in the current Debian *git* packaging into the PureOS packaging. Do you have good suggestion here?

Sorry, I have no suggestions on how to frame preparation routines which involves applying Debian changes on top of PureOS changes as "best practice" for maintaining packages forked from Debian.

Any preparation style regardless of non-metadata contents of the changelog file is acceptable (obeys all "must" in Policy).

Except that this is PureOS and not Debian so while it's certainly a good idea to follow Debian policy we shoudn't simply imply that Debian Policy is the only policy and that we need to adhere to all policy points.

True that it might be bad, but until T1047 is solved Debian Policy is what we got for PureOS!
If you are aware of anything broken or incomplete or overzealous for PureOS then please file a separate report for each issue and link them to T1047.

There are acceptable (obeys all "must" in Policy) and recommended (obeys all "must" and "should" in Policy) and suggested (follows best practices).

I'm not debating that debian/changelog could be improved.

No, but you are debating whether or not meshing changelogs makes them harder to understand.

I don't think [having a rule of "changelog should be a log"] is a good idea though since merging changelogs keeps valuable information around [...] and i don't think this would make it any harder for Debian to look at the diffs.

It would need to *become* a policy rule, it isn't one already.

Thanks for the clarification . sorry that I was unclear.

Evangelos wrote:

this was specifically about updating downstream packages (which was the in the initial title btw ;) ).

I am lost - I don't know what we are discussing here.
Possibly my own fault for a) speaking about things I find relevant before the scope of this issue report was properly established, and b) talking about things I explicitly stated previously that I find out of scope (notably requirements as opposed to best practices).

While that sounds like a cool feature, shouldn't the "responsibilities" be reversed? What I mean by that is: If we're carrying PureOS patches shouldn't we (by following the principle of upstream first) be the ones to propose upstreamable patches (to both the parent Debian packaging and/or the relevant upstream projects) instead of making the Debian maintainers having to go hunt for downstream patches?

...or correction: I have seen one tool that lists downstream git branches/commits for cherry-picking - that tool is git itself and is mighty great when you know which packaging style is used. Sure, quite likely the style used by the Debian GNOME team happens to be same (or similar enough) to the one we end up deciding for our git streamlined preparation of Debian packages - but that is missing my kay point:

I think most Debian developers use https://tracker.debian.org/

Ok, I will begin drafting a proposed PureOS Policy document, that we can then discuss.

I recommend to treat repo.pureos.net as essential and central for how we work in the PureOS team (i.e. not just an artifact store).

if this issue report is unrelated to T1048 then I apologize for spreading confusion, and will stand back until perhaps eventually more clear what it is about...

@jeremiah.foster: Among the things you summarize, it seems that only "use appropriate git tag" relates to T1048 and only weakly:
How do those best practices help address T1048?

This is about what ends up in the *changes* file for the upload, not the changelog entry.

I don't know rules for LTS, but the semi-official (i.e. officially .org hosted but officially unsupported) backports.debian.org seems to a) recomend including all changes compared to newest parent release in topmost changelog section(s):

It is recommended to include all changelog entries since the last version on debian-backports or since stable if it's the first version. You should do this by passing "-v" to dpkg-buildpackage. Eg: "debuild -v0.7.5-2", where "0.7.5-2" is the version in stable.

So like

gnome-calls (0.3.2-1pureos1) byzantium; urgency=medium
gnome-calls (0.3.0-2pureos2) byzantium; urgency=medium
gnome-calls (0.3.0-2pureos1) byzantium; urgency=medium
gnome-calls (0.3.0-1pureos1) byzantium; urgency=medium
gnome-calls (0.3.2-1) experimental; urgency=medium
gnome-calls (0.3.0-2) experimental; urgency=medium
gnome-calls (0.3.0-1) experimental; urgency=medium

?

Imagine we reach a conclusion to "find a criteria in the absence of any other authoritative source and to find consensus how to handle that" - does that mean we can close this issue report? No. That is my point.

It's not meta.

This issue says "let's discuss the seemingly 2 existing practices", and T1011 and T1012 says "we need the best practice automated".

I agree that (if we want to) we can mandate that package preparation must be done with git and must use gbp.
My point is that we cannot mandate "merging Debian tags", because that implies a parent Debian package prepared and tagged in a way compatible with gbp which is not always the case.

sorry, didn't mean to discredit you, @guido - just appears to me that this issue was filed by @evangelos.tzaras.

I find that issues work best when framed as something wrong - which can then be resolved either by disputing that the problem is real or by fixing it or by deciding that it exists but should not be fixed.

I think it makes sense to distinguish between a) package style (i.e. how we want to compose our final .deb packages released into PureOS) and b) package preparation style (i.e. how we want to keep track of the source components used for our package releases).

I see how my talking in git lingo is confusing here. Sorry!

Can you define close here?

I use git lingo, yes, but I am talking about .deb packaging which at its core is not git-based: Git and onther VCSes are merely an aid in handling the file-based package maintenance - where it certainly is extra helpful when both Debian and PureOS preparations are done using compatible VCS tools and routines.

I consider the current document to represent the equivalent of a mixture of Debian Developers' Reference and Debian New Maintainers' Guide and the Debian wiki.

@jeremiah.foster: If the current wiki page is as strict as it gets for PureOS and maintaining a more stable subset is considered overkill, then I guess simply close this issue report as wontfix.

It is not my impression that Lollypop wants to support opening videos - but that it wants to support audio (and probably also still images) in MPEG4 containers. But anyway since this issue seems to not be tied to how it is packaged for (Debian and) PureOS it makes better sense to discuss both issues upstream: Both the crashing bug and the potential idea for a feature request of limiting its scope (if its scope currently is loose and it tries to play not only audio but also video from multimedia files).

if you wanna change the issue from "lollypop fails to start in PureOS byzantium (laptop) but not on Byzantium mobile" then I suggest to close this issue report and file an issue upstream suggesting to change the scope of the application.

I am not well versed in reading debugger dumps, but this:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f5a43a0b995 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
[Current thread is 1 (Thread 0x7f5a77fff700 (LWP 19750))]

looks like the crash happens in the graphics driver, not in the application.

@mladen Do I understand it correctly that this issue affects only byzantium (not amber)?

network-manager-openvpn 1.8.14-1~pureos1 has now been queued for byzantium.
When it enters in landing it will be helpful if you could test and confirm that it works as expected, @mladen - thanks for the detailed investigation!

Really the package suggests a non-existent package which is not an issue.
Some package exist outside of PureOS which happen to contain non-free code, but the relevant issue here is whether PureOS is encouraging the use of non-free code which is not the case.

it is not a bug to recommend a non-existent package.

to me that sounds like there is no bug in the matrix-mirage package but instead a bug in the setup of the environment.

perhaps this? https://gitlab.gnome.org/World/lollypop/-/issues/2745

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