Using pureos/byzantium or pureos/amber with or without -phone is somewhat easier for me since it clarifies which branch is destined for which target suite. In my mind, pureos/latest points to the branch that you work from to create pureos/*.

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?

I reverted to an older document because the NEW Queue is 404'ing at the moment.

Let's keep in mind that we also implement, in the PureOS case, the tools that do package processing. This means we can mandate a set of git tags along with git (obviously) and gbp. I guess the issue with git tags is that some Debian packages do not use git tags, but we can add them for PureOS without much issue no?

For the record, this very issue report was not meant as "this package is totally WRONG" - which is the reason I marked it as severity normal.

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

Backports of an updated version of a package that was backported before may have a changelog that merges entries of backports of previous versions, but this is not required.

I propose to reframe this issue to say "best practice(s) is missing/undocumented".

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.

For Debian packages, there are no forking and resync'ing going on, so the changelog naturally behaves like a "log" - but when "meshing" multiple sources together, the arguably more natural thing to do is to mesh the log as well, which in my opinion is plain wrong and leads to a useless changelog file.

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

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.

@jonas.smedegaard point taken. I read that in relation to T1011 and T1012 above which kind of would codify what's asked here.

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.

(notice how each of the suggestions have some sort of bias...)

While git, git-buildpackage, and tagging releases in git are all popular, they are not required in Debian and therefore cannot be required in PureOS either.

Please do not expand this issue to become a meta discussion about what is common and what is uncommon: That is quite important to figure out but as separate issues.

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 opened https://tracker.pureos.net/T1049 for the meta discussion and will leave this open until the meta-issue has been clarified (as you suggested)

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

Can you define close here?

@sebastian.krzyszkowiak , thanks fixed!

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.

Please keep packaging close to its parent, by rebasing changes on top of latest Debian package release.

Rebasing? In the git sense of the word? Wouldn't that imply having to always force push to our packaging repositories (which would destroy/rewrite the git history)?

So would that be pureos/latest (instead of pureos/byzantium) and pureos/amber or pureos/amber-phone then?
Confusing!

the main development branch should be called debian/latest

Ticket is updated upstream. Closing this.

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.

Ticket is updated upstream. Closing this.

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

Yes this ticket needs an update. And there is already an ticket upstream made by me; https://gitlab.gnome.org/World/lollypop/-/issues/2768

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

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.

@jonas.smedegaard Yes. I'll will have the latest version tested and report back, thanks!

@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!

@evangelos.tzaras no idea how one drops drafts but i think i restored the original version.

this looks fixed in lanekia's new layout

3.38.2 is in byzantium now: https://software.pureos.net/package/bin/byzantium/libgdm-dev

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.

Feel free to delete my draft which arouse out of confusion around the Uploaders: field ;)

After a recent flashing of my L5, this is not an issue anymore.

the problem still persists on my Librem 5. I cannot download updates for tzdata and certificates

@guido here, and thanks for the link:

@jonas.smedegaard could you please work with @mladen to get this fix into byzantium (and ideally also Debian bullseye since this looks like it would qualify).

@joao.azevedo can you provide a backtrace: https://developer.puri.sm/Librem5/Development_Environment/Boards/Troubleshooting/Debugging.html?highlight=gdb#finding-core-dumps https://developer.puri.sm/Librem5/Development_Environment/Boards/Troubleshooting/Debugging.html?highlight=gdb#finding-core-dumps - otherwise the segfault says almost nothing about where the problem is happening.

Thanks for help

I'm sorry, we don't support any hardware that requires proprietary firmware. Your best bet is to install and use Debian with non-free repo enabled.

In T1046#18790, @mladen wrote:

This is unsupported hardware, you probably need proprietary firmware for nouveau driver...

How i can do it? Please, send link to instruction or something

This is unsupported hardware, you probably need proprietary firmware for nouveau driver...

updated, so closing

So, that RST packet is indeed the issue, and there's a high chance that either APT or GnuTLS don't handle this correctly. I talked with an APT developer, and we may actually need to debug this further in future.
In the meanwhile though, the issue can be mitigated by throwing an Apache2 webserver in front as proxy, instead of Nginx.

Some new observations:

• This is not a proxy server issue: Even without proxy, the issue occurs
• The TLS version doesn't matter at all
• Before the issue occurs, we get quite a few TCP retransmissions from the client to the server, and then the current connection is dropped:
  
• There is nothing suspicious in the Nginx logs, not even at info priority. A quick glance at the debug logs also didn't show anything interesting, but those are massive and it's possible that I missed something.

@guido Yes, okay to update. I'll do it unless you get to it first.

Then let's go with g) until / unless we determine this is unsuitable. It may lead to tags like "fixed in Byzantium" or "fixed in Amber" but those ought to be easily managed and I think we already have a "fixed in Byzantium" tag.

maybe-a-bug issue

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

In the field of voodoo magic:

@jonas.smedegaard since you packaged matrix-mirage you might be curious about this "bug".