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

gitlab would be nice too but likely fine grained (e.g. calls -> calls channel, phosh/phoc/squeekboard -> phosh channel) - we had a bug for that somewhere in gitlab iirc, the above is about the pureos tracker only.

to add some context:

@evangelos.tzaras for phone development you'd usually not use dput.

thanks @mak !

@jeremiah.foster how did i get pulled in here?

we have it in byzantium and amber-phone hence this can be closed.

Just to be clear: this is about https://repo.pureos.net/pureos-debug/dists/amber-debug/main/binary-arm64/Packages.xz and https://repo.pureos.net/pureos-debug/dists/byzantium-debug/main/binary-arm64/Packages.xz being empty (hence making debugging problems on user systems basically impractical).

yes, that is fixed in the recent upload and a tagged version is uploaded to amber-phone-staging.

since i don't have permissions to edit the content. If a package is blocked at https://master.pureos.net/migrations/
then it has Not touching package due to block request by laniakea in the list of excuses.

should that read 'If a package (source or binary) is new to a suite of the PureOS archive' since we need to new-process packages NEW in amber-phone that are in byzantium or is that a speciality of amber-phone?

@jeremiah.foster powetop shows the amount of power drawn from the battery as a rough indicator

@jeremiah.foster could you check if min_power makes a difference? It seems to save 0.5W here things are fluctuating quite a bit so a longer test would be good.

@mak how much disk space would that be ? @jeremiah.foster @nicole can you get us the necessary disk space?

something like https://wiki.archlinux.org/index.php/Power_management#SATA_Active_Link_Power_Management

i wouldn't call it frozen, it's just that the settings and app menu grab all input (i pretty much got used to it and just hit ESC in these situations). This is fixable but not in phosh alone, phoc needs to help here. I'd be great to have a bug on phosh as well since this also affects convergence.

phosh itself is not involved here, if at all it's the compositor. @david.hamner could you file a phoc bug because having bugs in upstream software will likely get lost.

Would still be awesome to have since this limits debugability considerably (people need to fetch packages from CI or Debian to get usable back traces for software we develop) - but maybe these packages are there and i dont know where?