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

Upstream issue: https://gitlab.gnome.org/World/lollypop/-/issues/2768

[DEBUG] 2021-04-14 13:40:24 Importing audio file:///home/joao/Music/fuck\ it-jZIoxw0ca9E.mp4
[DEBUG] 2021-04-14 13:40:24 LazyLoadingView::lazy_loading(): 0.33496856689453125
Segmentation fault

This package version is found in Debian experimental: https://packages.debian.org/experimental/network-manager-openvpn

@sebastian.krzyszkowiak I am not aware, I could not find anything on their bug tracker. But this issue has been fixed with https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/34 and it seems that version with the fix, v1.8.14, is released already.

We're using network-manager-openvpn from Debian - is there an issue for that in Debian's bugtracker?

@jonas.smedegaard I am not sure.

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

I meant T1024.

@jeremiah.foster o.k. to update the docs?

Le't leave it as is then for now (since this seems current PureOS practice):

@jonas.smedegaard i think you mean https://tracker.pureos.net/T1028 not https://tracker.pureos.net/T1023 above? (this issue is T1023)?

Strictly speaking, this issue is about Maintainer field. T1023 was about Vcs-* fields.

Two more questions:

having the these texts in a form that is suitable for c'n'p would help:

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

@ezs777 thanks for confirming it works for you!

This was fixed when the latest update of nautilus, which I applied this morning.

Architecturally this should actually be implemented in such a way that a bugtracker change emits a new message on Laniakea's ZeroMQ-based message-bus, and that message is then picked up by the Matrix bot and relayed to the channel
that way, other consumers can pick up the messages as well and act on them for other purposes than showing a channel message (that's how automatic bug closing was implemented in the past, actually)
(but "in the past" means deep in the past where Trac was used for bugtracking)
The messages Laniakea sends are multipart-ZeroMQ messages with a header/subject in rDNS form, like _lk.archive.new-package and a JSON body with a few standardized fields and one freeform "data" part. The JSON part is signed with an Ed25519 signature from the messaging relay, so messages can be authenticated as correct
(message submission happens via a Curve25519-encrypted connection to a relay, from where they are distributed to interested parties)
and yes, this should absolutely be documented properly ;-)
Fortunately, the Laniakea Python module has helpers for this stuff so you don't have to touch it directly - in theory all this needs is a consumer of bug tracker events that submits them to the relay, and then the Matrix bot only needs to be told how to convert the messages into human-readable form

openvpn: 2.5.1-1
network-manager-openvpn: 1.8.12-2

https://github.com/lkhq/laniakea/tree/master/src/mirk is the tool we use to push to Matrix.

With which version of openvpn? Some of the links you provided indicated older versions of openvpn were the issue, we have a newer version in Byzantium now.

see https://source.puri.sm/Librem5/debs/nautilus/-/issues/3

@jeremiah.foster We already reproduced the issue with Librem Tunnel.

I guess the next step is to try to reproduce with Librem Tunnel.