This issue tracker is for issues with PureOS.
Not for issues with non-PureOS packages - e.g. using PPAs or flatpak or Snap.

PureOS is mostly tested with GNOME as desktop.

Thanks for reporting.

PureOS is mostly tested with GNOME as desktop.
I am uncertain if this issue is actionable at all for us - i.e. if we have anyone skilled with KDE to debug this kind of issue, or we should simply give up and close it as a wontfix.

I guess our flatpak expert is @jeremiah.foster - please reassign if I am mistaken.

Packaged for Debian: https://tracker.debian.org/pkg/dialect

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.