Firefox-esr is in Byzantium-security: https://software.pureos.net/package/bin/byzantium-security/firefox-esr

MR https://salsa.debian.org/mozilla-team/firefox/-/merge_requests/5

A quick search brought up https://bugzilla.mozilla.org/show_bug.cgi?id=1627713

@jbw See https://developer.puri.sm/Librem5/Development_Environment/Boards/Troubleshooting/Debugging.html#installing-debug-packages

Everything that gets uploaded to the archive gets built for arm64 (librem5) automatically.

@carsten.schoenert I think we want base-files 11.1+debu11u1 + pureos changs, yes but @mak should confirm. What puzzles me is that it doesn't show up at https://master.pureos.net/sync/landing

We consider byzantium to be stable now. Awesome list btw!

Screenshot works for me (it's not adaptive and only capturing the full screen works) but I use it all the time.

@carsten.schoenert happy to help here, first good step would be a MR against the above repo with the necessary changes. I usually do

The linitan check is about the fields in d/control. I doesn't care who signs/uploads the package later on.

The name "Hephaestus" is going to be deprecated and removed in favor of just the version number, e.g. PureOS 9 Amber, Pureos 10 Byzantium, etc.

Sorry for the open/close ping pong but the issue is still there (and not a dup, i'll clarify in the other issue).

For completeness, you're referring to https://pureos.net/ ?

@carsten.schoenert i've created https://source.puri.sm/pureos/packages/lollypop by mirroring https://salsa.debian.org/python-team/packages/lollypop.git (see https://source.puri.sm/Librem5/librem5-dev-tools/-/issues/1 for the steps) since i wasn't sure if you have all the permissions set up yet.

It's not a rejection reason (afaik Laneakia doesn't reject based on linitan errors yet) so likely not security relevant or am i missing something?

I can handle this low priority for the moment, i found ways to build geary for the moment but i expect this issue to become more urgent during the byznatium cycle again (if not for geary then for other packages using vala). Issue here is that this will likely involve a glib upgrade as well.

Interesting experiment by smvc. As noted above we can build from git *but* lack the laneakia integration so this currently foremost needs some input from @mak how we want to proceed there (i.e. what part of the laneakia system fetches from git, do we still build source packages, do we use shim .changes files or do away with all of this)? I'd go for initially mimiciing current build process as much as possible (have a art in laneakia that watches git repos, if a signed tag pops up verify that build a source package and submit it to the existing infrastructure and then work from there. But then again this depends if we want to work on something that works for Debian as well, etc.

From my side this can be closed since i don't think amber matters much at this point. I'm not sure what the PureOS policy is here? Close once the release goes fully out of service? @jeremiah.foster ?

From my side we an close this since zanata isn't in use by any Purism project anymore afaik.

see https://source.puri.sm/Librem5/librem5-base/-/merge_requests/248#note_158021

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 !

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

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

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.

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

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?

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.

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

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

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

I went ahead and fixed the link.

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.

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.

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.

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

@sebastian.krzyszkowiak , thanks fixed!

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

Ticket is updated upstream. Closing this.

@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

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

updated, so closing

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

Two more questions:

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

@ezs777 thanks for confirming it works for you!

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

I think that's what we should do, see above

@jeremiah.foster location services are off by default, this is for the case where the user enables it. Would you drive that process since it affects all devices running PureOS the same way??

@jeremiah.foster any plans here? Should that go via the sys-team to manage all api keys?

removed from landng as per request

odd tarball in the archive - lets revisit for > 0.4.0

cleaned up in landing

we can close this since we can't clean it up for byzantium due to a tarball checksum mismatch - i lack the power to close bugs thouh.

Note that on the phone side we use a separate system to allow for this but it woudl be great if laneakia would handle that natively since this would shorten the pipeline where anything could go wrong and it makes it quicker to spot problems.

A likey simple way would be to assume a fixed location in gitlab like