Page MenuHomePureOS Tracker

Open Tasks

Needs Triage (15)

Recent Activity

Yesterday

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

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.

Fri, May 7, 03:44
jonas.smedegaard added projects to T1030: phosh: Vcs-Browse and Vcs-Git points to Debian: Restricted Project, Restricted Project.
Fri, May 7, 03:36 · Restricted Project, Restricted Project
jonas.smedegaard added projects to T1028: rust-xkbcommon: Vcs-Browser and Vcs-Git points to Debian: Restricted Project, Restricted Project.
Fri, May 7, 03:36 · Restricted Project, Restricted Project
jonas.smedegaard added a project to T1026: uefitool: Vcs-Browser and Vcs-Git not declared: Restricted Project.
Fri, May 7, 03:34 · Restricted Project
jonas.smedegaard added projects to T1025: util-linux: Vcs-Browse and Vcs-Git points to Debian: Restricted Project, Restricted Project.
Fri, May 7, 03:34 · Restricted Project, Restricted Project
jonas.smedegaard added projects to T1022: webkit2gtk: Vcs-Browse and Vcs-Git points to Debian: Restricted Project, Restricted Project.
Fri, May 7, 03:33 · Restricted Project, Restricted Project
guido added a comment to T1034: network-manager-openvpn: fails to work with Librem Tunnel and some other OpenVPN services on byzantium.

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

Fri, May 7, 03:32 · Restricted Project
jonas.smedegaard added projects to T1021: wlroots: Vcs-Browse and Vcs-Git points to Debian: Restricted Project, Restricted Project.
Fri, May 7, 03:31 · Restricted Project, Restricted Project
jonas.smedegaard added a project to T1020: wys: Vcs-Browse and Vcs-Git points to Debian: Restricted Project.
Fri, May 7, 03:30 · Restricted Project
jonas.smedegaard added a project to T1027: squeekboard: Vcs-Browser and Vcs-Git not declared: Unknown Object (Project).
Fri, May 7, 03:22 · Unknown Object (Project), Restricted Project
jonas.smedegaard added a project to T1027: squeekboard: Vcs-Browser and Vcs-Git not declared: Restricted Project.

Status update:

  • squeekboard 1.11.1 in amber is still missing Vcs-* hints
  • squeekboard 1.13.0-1pureos1 in byzantium is good
Fri, May 7, 03:17 · Unknown Object (Project), Restricted Project

Thu, May 6

mladen closed T1034: network-manager-openvpn: fails to work with Librem Tunnel and some other OpenVPN services on byzantium as Resolved.
Thu, May 6, 13:35 · Restricted Project
mladen added a comment to T1034: network-manager-openvpn: fails to work with Librem Tunnel and some other OpenVPN services on byzantium.

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

Thu, May 6, 13:35 · Restricted Project
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Thu, May 6, 07:17
jonas.smedegaard added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Thu, May 6, 06:34
evangelos.tzaras added a comment to T1049: pureos: unclear how to best update downstream forks.

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.

Thu, May 6, 04:13
guido updated subscribers of T1049: pureos: unclear how to best update downstream forks.

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.

Thu, May 6, 02:52
guido added a comment to T1049: pureos: unclear how to best update downstream forks.

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

Thu, May 6, 02:27

Wed, May 5

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