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

@jeremiah.foster people are stepping on this while trying to bootstrap amber on Debian - would you take a stab of trying to get this into mainline deboostrap so boostrapping pureos becomes simpler everywhere in the future? I'm happy to help here.

I don't know how many people use this feature on Debian but I doubt that many people concerned about privacy, as Librem users are, will want to switch this feature on.

related https://source.puri.sm/Librem5/Apps_Issues/issues/162 - i think it would be a good feature to have if people opt in - it's by no means about convenience but to give us enough data to fix issues. It's also data that might be hard for the user to provide.

I've created a dpkg reppo at

@mak gcr secmem is similar to what gpg's gtksecentry does using

just to add the detail how things will break for users

• use https://github.com/debuerreotype/debuerreotype/pull/63
• then s.th. like (just a quick hack):

Just as a data point: I am a daily startpage user but it has availability and performance problems. I switch to ddg every now and then when startpage does not respond but that is not something we want to put on our users (that's why I opted to merge the ddg patch for the moment).

The same thing came up realted to GNOME Web: https://source.puri.sm/Librem5/librem5-base/merge_requests/36 - phone and laptops should ship the same list (only exception I could see is a engine with super nice search results that doesn't work on mobile)

hmm...but it also claims it already knows about 0.0.3:

reuploaded.

But source only packages don't have binary fields, do they?

$ diff -u librem5-devkit-tools_0.0.2_source.changes librem5-devkit-tools_0.0.2_amd64.changes 
--- librem5-devkit-tools_0.0.2_source.changes	2019-05-10 09:40:03.547341329 +0200
+++ librem5-devkit-tools_0.0.2_amd64.changes	2019-05-10 09:40:03.251334929 +0200
@@ -1,12 +1,16 @@
 Format: 1.8
 Date: Thu, 03 Jan 2019 18:14:54 +0100
 Source: librem5-devkit-tools
-Architecture: source
+Binary: librem5-devkit-check librem5-devkit-host
+Architecture: source all
 Version: 0.0.2
 Distribution: green
 Urgency: medium
 Maintainer: Guido Günther <agx@sigxcpu.org>
 Changed-By: Guido Günther <agx@sigxcpu.org>
+Description:
+ librem5-devkit-check - Check script for the librem5-evk (devkit)
+ librem5-devkit-host - Tools for the librem5 devkit (host side)
 Changes:
  librem5-devkit-tools (0.0.2) green; urgency=medium
  .
@@ -50,12 +54,18 @@
 Checksums-Sha1:
  81e28197203dca97ff08210434712b507af87e4e 807 librem5-devkit-tools_0.0.2.dsc
  6fa81bb4a16c215876d90a0b5621694606f4499f 3145044 librem5-devkit-tools_0.0.2.tar.xz
+ af677461b38832c9bf982731c7e2da25f4d32c08 4344 librem5-devkit-check_0.0.2_all.deb
+ 98a5091e26dd981556b6af50f27956685ac96739 7292 librem5-devkit-host_0.0.2_all.deb
  44505ad3ed264d8f36050ccce0f5d8aaa6152281 5586 librem5-devkit-tools_0.0.2_amd64.buildinfo
 Checksums-Sha256:
  9e2678e5f7f47e0bea0bb5e4d4a444ac55cf1277ba6f758de4cb7ab4fa7bca61 807 librem5-devkit-tools_0.0.2.dsc
  409c7da987f61417393a3b9a6928db6f6fb126785e830c292515a1053787c326 3145044 librem5-devkit-tools_0.0.2.tar.xz
+ f868c11abb80cb704a275bbb0aad829553fc03b81e7779f1f04e33459d7a5397 4344 librem5-devkit-check_0.0.2_all.deb
+ bf2ffd3d7cc9ffcf14295bb88f021cf6b38286437e3c3aa8b2dd37b5318a4d0e 7292 librem5-devkit-host_0.0.2_all.deb
  8ea700fb34b8ef045ca5fa89cd42d4315da8769686da1f9e764d329ce509a7f8 5586 librem5-devkit-tools_0.0.2_amd64.buildinfo
 Files:
  9d92f14fb555cdb72716629b18ac7535 807 utils optional librem5-devkit-tools_0.0.2.dsc
  abf12ff17e58b7bc620e80bd4784954a 3145044 utils optional librem5-devkit-tools_0.0.2.tar.xz
+ 1f4bec1041b0a3824402e7b913dedb01 4344 utils optional librem5-devkit-check_0.0.2_all.deb
+ 06c0b6e379a2770c5d491f72e2caeafe 7292 utils optional librem5-devkit-host_0.0.2_all.deb
  cda9774535ca4072ee0b89d7ec4c2e5e 5586 utils optional librem5-devkit-tools_0.0.2_amd64.buildinfo

A plain pbuilder (dpkg-buildpackage) build and then using the _source.changes

I've added support to debuerreotype for that https://github.com/debuerreotype/debuerreotype/pull/63 and put current images here: https://hub.docker.com/r/godiug/pureos/tags

webrtc progress: https://blogs.gnome.org/tsaunier/2018/07/31/webkitgtk-and-wpe-gains-webrtc-support-back/

I've reuploaded the same package I uploaded on jan 3rd. source package is librem5-devkit-tools.

Other possibly interesting stuff:

uploaded mfgtools_1.2.91+0git6b465-0pureos+librem5.1_amd64.changes

The corresponding source package (librem5-devkit-tools) was uploaded but the librem5-devkit-host package did not make it into the archive. @mak did some investigations on why that happened but I don't think there was a clear outcome.

From the phone perspective we we'd like to pull a rather fixed set of packages from e.g. Debian experimental during the freeze automatically (assuming Debian's GNOME team ends up putting the packages there) but after all it's more of an example of a general pattern: grab packages a, b, c from repository x (ideally including required dependencies not present in the target distribution).

@jeremiah.foster Packaging is here: https://source.puri.sm/Librem5/mfgtools/tree/pureos/purple

This is also related to https://tracker.pureos.net/T594

I've put initial packaging here https://source.puri.sm/Librem5/mfgtools/tree/pureos/purple .
RFP for Debian is . I'm happy to maintain this in Debian if someone from the PureOS team joins me.

Just for reference: https://source.puri.sm/Librem5/librem5-devkit-tools - it will gain a librem5-devkit-host part with the next MR.

@sean.obrien (this might become a bit off topic): the flatpak side needs more work for the 3rd party apps.

We have purple and laboratory in PureOS and the CI repos for phone development.

Please see the GNOME case above, this is really not tied to our CI.

You have me confused now. I thought the whole transitioning between landing -> and green is there to detect these inconsistencies?
Also I'd be syncing for me does not imply syncing binaries. Rebuilding the ones not synced from testing would be a great first step in rebuilding everything.

Uploading to once place is more comfortable than to two ;)

I'm wondering if this is on anyone's horizon yet? If not I would put it on my TODO list since it would be good to have this running so we can test phone stuff on PureOS in gitlab's CI as well (instead of "only" Debian testing).

If we fix the underlying issue all users logged into a GNOME session will be in the KVM group and no additional work is necessay, it works out of the box (as users would expect). Just pull this systemd patch into PureOS: