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

0.0.11-1pureos1 can be removed from buzantium and we can switch to the Debian version. There's no downstream changes in there, it was just a rebuilt since the package wasn't in Debian at that time.

a an issue that remains is that we don't have debug packages for regular pureos-amber. This can often be helped by using the ones from Debian but not always when e.g. pureos lacks a bit behind. This makes it unsafe to enable by default.

dbgsym packages for amber-phone-staging do work now via

@mak main issue here is that i can't tell if the correct match string (so i did not use any wildcards) or if there are other devices with the same match that might break.

That is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765936 and documented here documented in /usr/share/doc/libvirt-daemon/README.Debian.gz . It would be best to just set the correct capability in pureos (setcap cap_net_admin+ep /usr/lib/qemu/qemu-bridge-helper)

@jeremiah.foster great! i'd skip amber-phone since it's just an overlay and we want to merge for byzantium anyways.

Yeah, i've seen that but that assume the user understands what is going on (and involves user intervention for s.th. that could be automatic).

With unbreak i mean it prints the symbols shown on the buttom instead of '#' which left the user pretty stranded when doing math stuff (or wanting to use the pipe symbol in the shell)

just to avoid duplication, i've uploaded these to green and amber a while ago: https://software.pureos.net/search_pkg?term=mfgtools - green is no more though. ci builds are here: https://arm01.puri.sm/job/debs/job/deb-mfgtools-buster-amd64/

on https://repo.pureos.net/pureos-debug/dists/ there's dbgsym packages for amber, amber-phone-staging and amber-proposed-upates so if the versions in amber-phone / amber-updates are the same we can work around things by using these.

that wold be so super cool since it would prevent dragging around deboostrap scripts by hand.