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.

see https://source.puri.sm/Librem5/librem5-base/-/merge_requests/248#note_158021

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

ok, some points about this:

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

If anything, I am not using my librem13 at the moment, the only thing I did is install PureOS and updated it, if you need more output of commands, I'l be happy to help))

A user reported that after an update chromium was installed in his system: https://forums.puri.sm/t/chromium-installing-automaticly-when-updating/13507

The link goes to Debian branded page with little or no useful content at the moment. Filed issue.

My frustration is with packages released with changelog files containing something else than a strict log of release changes. Regardless of tooling!

With "a strict log of release changes" I mean that each section of the logfile summarizes the change between that and the previous section of that file.

Cool stuff, thanks @jonas.smedegaard , @mladen !

Status update:

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

Confirmed, the network-manager-openvpn 1.8.14-1~pureos1 fixes the issue! Thank you @jonas.smedegaard

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

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.

To me, best practice of maintaining a fork prioritizes keeping the difference to a minimum over keeping the maintenance work to a minimum.

NB! I certainly welcome reducing the maintanance burden, I am only talking about the priority of those to qualities: Ideally both should be minimal.

Just to make sure we understand each other: What you call "artifacts" are tangible by-products, right? For comparison, what I call "products" are the packages we ship to our users (not throw-away results of test builds).

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.

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.

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

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

When you do a git merge then changelog files are meshed, and when you follow "strategy b)" you don't. That seems rather consequential to me, not orthogonal.

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 cannot decipher if release 1.14.12-0.1pureos1~amber1 is just "uploaded" and "backported" compared to release 1.14.12-0.1 - i.e. if the patches mentioned for release 1.14.10-0.1~pureos0~amber1 was applied as well or not.