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.

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.