Page MenuHomePureOS Tracker
Feed All Stories

Yesterday

jonas.smedegaard added a comment to T1012: Please provide scripts to update downstream forks.

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.

Wed, May 5, 12:34
mladen created an object: Format and use secondary disk.
Wed, May 5, 12:21
jonas.smedegaard added a comment to T1011: Please provide scripts to create downstream forks.

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.

Wed, May 5, 12:10
jonas.smedegaard added a comment to T1011: Please provide scripts to create downstream forks.

I am not fluent in Gitlab, but for the local repo part, I use this:

#!/bin/sh
Wed, May 5, 12:07
mladen edited the content of Tips & Tricks.
Wed, May 5, 11:47
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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.

Wed, May 5, 11:36
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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.

Wed, May 5, 11:23
guido added a comment to T1049: pureos: unclear how to best update downstream forks.

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.

Wed, May 5, 10:31
guido added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Wed, May 5, 10:28
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Wed, May 5, 05:57
evangelos.tzaras added a comment to T1049: pureos: unclear how to best update downstream forks.

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.

Wed, May 5, 04:54
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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.

Wed, May 5, 02:56
guido added a comment to T1049: pureos: unclear how to best update downstream forks.

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.

Wed, May 5, 02:02

Tue, May 4

jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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.

Tue, May 4, 04:02
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

It would need to *become* a policy rule, it isn't one already.

Thanks for the clarification . sorry that I was unclear.

Tue, May 4, 03:43
guido added a comment to T1049: pureos: unclear how to best update downstream forks.

I am talking about the Debian standard for well-structured patches DEP-3 (not DEP-5)
Debian tracker currently link to a single dumb delta between the forked Ubuntu package and its Debian parent (not DEP-3 patches)
my vision is for PureOS to provide DEP-3 patches to ease reuse outside of PureOS - e.g. linked from same place that now links to dumb Ubuntu patches (not that PureOS provide dumb patches like Ubuntu - which I agree is doable regardless of how packages are prepared but is less helpful than DEP-3 patches).

Tue, May 4, 03:23
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

Evangelos wrote:

this was specifically about updating downstream packages (which was the in the initial title btw ;) ).

Tue, May 4, 02:49

Mon, May 3

evangelos.tzaras renamed T1049: pureos: unclear how to best update downstream forks from pureos: best practice(s) is missing/undocumented to pureos: unclear how to best update downstream forks.
Mon, May 3, 20:08
evangelos.tzaras added a comment to T1049: pureos: unclear how to best update downstream forks.

@evangelos.tzaras: Is the issue you reported here broadly about any and all best any practice(s) in PureOS missing or undocumented?

Mon, May 3, 20:08
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Mon, May 3, 08:11
guido added a comment to T1049: pureos: unclear how to best update downstream forks.

I would love to have https://tracker.debian.org/ also link to PureOS patches - and I see how that is doable by parsing Debian Policy standards-compliant source packages and look for DEP-5 standards-compliant patches. Which standards should I follow to implement such feature for git branches/commits?

Mon, May 3, 07:23

Sun, May 2

hikochat created T1050: Cool Reader, OpenRA, OpenLoco, moodle.
Sun, May 2, 06:20
hikochat placed T996: Youtube-dl, Pinta, Libretranslate up for grabs.
Sun, May 2, 06:15
sambattherford updated sambattherford.
Sun, May 2, 00:07
sambattherford updated sambattherford.
Sun, May 2, 00:07

Fri, Apr 30

jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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?

Fri, Apr 30, 08:28
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Fri, Apr 30, 08:16
evangelos.tzaras added a comment to T1049: pureos: unclear how to best update downstream forks.

I would love to have https://tracker.debian.org/ also link to PureOS patches - and I see how that is doable by parsing Debian Policy standards-compliant source packages and look for DEP-5 standards-compliant patches. Which standards should I follow to implement such feature for git branches/commits?

Fri, Apr 30, 08:15
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

I think most Debian developers use https://tracker.debian.org/

Fri, Apr 30, 08:06
guido added a comment to T1049: pureos: unclear how to best update downstream forks.

Similary, when we need changes to the packaging of epiphany, we should do that "upstream first" as well: We should have in mind that the epiphany package is maintained as part of Debian and we prefer to not maintain a fork forever, so we should play nice with upstream and try make it easy for them to grab and adopt our changes.

Fri, Apr 30, 07:32
jonas.smedegaard added a comment to T1047: PureOS has no strict policy of mandated packaging requirements.

Ok, I will begin drafting a proposed PureOS Policy document, that we can then discuss.

Fri, Apr 30, 04:23
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Fri, Apr 30, 03:46
guido added a comment to T1049: pureos: unclear how to best update downstream forks.

This still leaves the question of best practices with respect to downstream forks of Debian packages (see item a) and item b) in the opening post).

Fri, Apr 30, 01:34
guido updated subscribers of Uploading Packages to PureOS.

Thanks for expanding @jeremiah.foster you're duplicating partly content from Tracing the package after the upload though. what about dropping that and just referencing the Tracing the package after the upload

Fri, Apr 30, 01:14
guido added a comment to Packaging Overview.

@evangelos.tzaras you only have *both* `pueros/latest and pureos/byzantium once byzatium is no longer the current development version. See https://dep-team.pages.debian.net/deps/dep14/ . The upside of pureos/latest is that you'd not be constantly busy with switching the repos default branch and name. It's basically the same as we do within DebianOnMobile with debian/master.

Fri, Apr 30, 01:11 · Restricted Project, Restricted Project, Restricted Project
guido added a comment to NEW Queue.

I went ahead and fixed the link.

Fri, Apr 30, 01:07 · Restricted Project
guido published a new version of NEW Queue.
Fri, Apr 30, 01:05 · Restricted Project

Thu, Apr 29

evangelos.tzaras added a comment to T1049: pureos: unclear how to best update downstream forks.

I could've maybe worded it more clearly in the OP: I was mostly concerned with how to update packages - especially when we're a downstream of Debian.
The question arose because of T1048 and the discussion that ensued around how d/changelog should look like.

Thu, Apr 29, 14:54
evangelos.tzaras added a comment to Packaging Overview.

I was mostly confused whether this would imply that we would have both pureos/latest and pureos/byzantium.

Thu, Apr 29, 14:36 · Restricted Project, Restricted Project, Restricted Project
jeremiah.foster claimed T1043: Lintian on PureOS should check that Vcs-Git points to https://source.puri.sm.
Thu, Apr 29, 13:08
jeremiah.foster reassigned T1047: PureOS has no strict policy of mandated packaging requirements from jeremiah.foster to jonas.smedegaard.
Thu, Apr 29, 13:08
jeremiah.foster added a comment to T1047: PureOS has no strict policy of mandated packaging requirements.

Yes, let's create a PureOS Policy document. To be clear, we base it on Debian Policy and we add the parts where PureOS deviates. The document is meant to be an authoritative requirements document so ought to use nomenclature to indicate requirement levels either identical to Debian's nomenclature or the IETF nomenclature: https://tools.ietf.org/html/rfc2119

Thu, Apr 29, 13:07
jeremiah.foster added a comment to Packaging Overview.

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/*.

Thu, Apr 29, 12:55 · Restricted Project, Restricted Project, Restricted Project
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Thu, Apr 29, 12:37
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Thu, Apr 29, 12:32
jeremiah.foster added a comment to NEW Queue.

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

Thu, Apr 29, 12:27 · Restricted Project
jeremiah.foster published a new version of NEW Queue.
Thu, Apr 29, 12:26 · Restricted Project
jeremiah.foster edited the content of Uploading Packages to PureOS.
Thu, Apr 29, 12:21
jeremiah.foster added a comment to T1049: pureos: unclear how to best update downstream forks.

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?

Thu, Apr 29, 10:55

Wed, Apr 28

evangelos.tzaras added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

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.

Wed, Apr 28, 23:39
jonas.smedegaard added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

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

Wed, Apr 28, 11:07
jonas.smedegaard renamed T1049: pureos: unclear how to best update downstream forks from Discussion: How to update downstream forks? to pureos: best practice(s) is missing/undocumented.
Wed, Apr 28, 10:36
guido added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.
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.
Wed, Apr 28, 09:27
evangelos.tzaras added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Wed, Apr 28, 09:18
jonas.smedegaard added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

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.

Wed, Apr 28, 07:39
guido added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

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.

Wed, Apr 28, 07:19
jonas.smedegaard added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

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

?

Wed, Apr 28, 06:36
jonas.smedegaard added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

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.

Wed, Apr 28, 06:11
jonas.smedegaard added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

It's not meta.

Wed, Apr 28, 06:09
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

This issue says "let's discuss the seemingly 2 existing practices", and T1011 and T1012 says "we need the best practice automated".

Wed, Apr 28, 05:59
guido added a comment to T1049: pureos: unclear how to best update downstream forks.

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.

Wed, Apr 28, 05:42
guido added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Wed, Apr 28, 05:38
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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.

Wed, Apr 28, 05:21
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

sorry, didn't mean to discredit you, @guido - just appears to me as if this issue was filed by @evangelos.tzaras.

Wed, Apr 28, 05:15
guido added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Wed, Apr 28, 04:26
guido added a comment to T1049: pureos: unclear how to best update downstream forks.

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.

Wed, Apr 28, 04:21
guido added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

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.

Wed, Apr 28, 04:18
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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.

Wed, Apr 28, 03:41
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Wed, Apr 28, 03:29
evangelos.tzaras added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

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)

Wed, Apr 28, 03:07
evangelos.tzaras created T1049: pureos: unclear how to best update downstream forks.
Wed, Apr 28, 03:07
jonas.smedegaard added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

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

Wed, Apr 28, 03:05
jonas.smedegaard added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

Can you define close here?

Wed, Apr 28, 02:55
guido added a comment to Packaging Overview.

@sebastian.krzyszkowiak , thanks fixed!

Wed, Apr 28, 02:46 · Restricted Project, Restricted Project, Restricted Project
guido edited the content of Packaging Overview.
Wed, Apr 28, 02:45 · Restricted Project, Restricted Project, Restricted Project
jonas.smedegaard added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

I use git longo, 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.

Wed, Apr 28, 02:39
guido added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

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

Wed, Apr 28, 02:36
evangelos.tzaras added a comment to T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.

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

Wed, Apr 28, 02:05
jonas.smedegaard renamed T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes from gnome-calls: changelog has parent Debian changes and changes of local fork intertwined to gnome-calls: changelog has parent Debian changes interleaved with PureOS changes.
Wed, Apr 28, 01:03
jonas.smedegaard triaged T1048: gnome-calls: changelog has parent Debian changes interleaved with PureOS changes as Normal priority.
Wed, Apr 28, 01:00
evangelos.tzaras added a comment to Packaging Overview.

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

Wed, Apr 28, 00:42 · Restricted Project, Restricted Project, Restricted Project

Tue, Apr 27

sebastian.krzyszkowiak added a comment to Packaging Overview.

the main development branch should be called debian/latest

Tue, Apr 27, 20:49 · Restricted Project, Restricted Project, Restricted Project
guido added a comment to T1044: lollypop fails to start in PureOS byzantium (laptop) but not on Byzantium mobile..

Ticket is updated upstream. Closing this.

Tue, Apr 27, 05:05
jonas.smedegaard added a comment to T1047: PureOS has no strict policy of mandated packaging requirements.

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.

Tue, Apr 27, 01:22
jonas.smedegaard added a comment to T1047: PureOS has no strict policy of mandated packaging requirements.

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

Tue, Apr 27, 00:46
jonas.smedegaard triaged T1047: PureOS has no strict policy of mandated packaging requirements as Normal priority.
Tue, Apr 27, 00:37

Mon, Apr 26

jeremiah.foster published a new version of Building Packages With Git-buildpackage.
Mon, Apr 26, 11:45
jeremiah.foster edited the content of Building Packages With Git-buildpackage.
Mon, Apr 26, 11:41
jonas.smedegaard triaged T1009: rust-xkbcommon: Please drop 0.4.0-0pureos1 from landing as Normal priority.
Mon, Apr 26, 10:57
jonas.smedegaard renamed T1009: rust-xkbcommon: Please drop 0.4.0-0pureos1 from landing from Please drop rust-xkbcommon 0.4.0-0pureos1 from landing to rust-xkbcommon: Please drop 0.4.0-0pureos1 from landing.
Mon, Apr 26, 10:56
joao.azevedo closed T1044: lollypop fails to start in PureOS byzantium (laptop) but not on Byzantium mobile. as Invalid.
Mon, Apr 26, 10:48
joao.azevedo added a comment to T1044: lollypop fails to start in PureOS byzantium (laptop) but not on Byzantium mobile..

Ticket is updated upstream. Closing this.

Mon, Apr 26, 10:48
jonas.smedegaard added a comment to T1044: lollypop fails to start in PureOS byzantium (laptop) but not on Byzantium mobile..

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

Mon, Apr 26, 10:33
joao.azevedo added a comment to T1044: lollypop fails to start in PureOS byzantium (laptop) but not on Byzantium mobile..

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

Mon, Apr 26, 10:14
jonas.smedegaard added a comment to T1044: lollypop fails to start in PureOS byzantium (laptop) but not on Byzantium mobile..

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.

Mon, Apr 26, 10:08
joao.azevedo added a comment to T1044: lollypop fails to start in PureOS byzantium (laptop) but not on Byzantium mobile..

I am not well versed in reading debugger dumps

Mon, Apr 26, 09:54
jonas.smedegaard added a comment to T1044: lollypop fails to start in PureOS byzantium (laptop) but not on Byzantium mobile..

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.

Mon, Apr 26, 08:59
mladen added a comment to T1034: network-manager-openvpn: fails to work with Librem Tunnel and some other OpenVPN services on byzantium.

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

Mon, Apr 26, 08:07 · Restricted Project
jonas.smedegaard added a comment to T1034: network-manager-openvpn: fails to work with Librem Tunnel and some other OpenVPN services on byzantium.

@mladen Do I understand it correctly that this issue affects only byzantium (not amber)?

Mon, Apr 26, 06:08 · Restricted Project
jonas.smedegaard added a comment to T1034: network-manager-openvpn: fails to work with Librem Tunnel and some other OpenVPN services on byzantium.

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!

Mon, Apr 26, 05:58 · Restricted Project