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:

Ubuntu's scripts (/usr/share/debootstrap/scripts) are also in Debian. Would be great if the same were to be true for pureos since that would tickle to all downstreams and enable many more people to contribute without hazards.

There's also tools like vmdeboostrap that invoke deboostrap / pbuilder directly. It would be much simpler if they could work out of the box.

can we get rid of this hack? There will be more people contributing to pureos in the future (phone team).

@mak then what about

(this relates to the original topic of recompiling packages not about having to rebuild because we carry patches)

@chris.lamb as noted in https://bugs.debian.org/889990 I think logind should adjust the ACL as it does for the dri and audio devices.

sudo adduser <youruser> kvm

newgrp kvm
killall libvirtd
libvirtd

I think I've found the issue: Can you try to add the user to the KVM group and see if it helps?

Any chance somebody could run the above

What version of libvirt, qemu and gnome-boxes is pureos currently shipping? Any patches on top of Debian proper?

@kyle.rankin the setcap is only for a follow up problem. It won't help with the CPU type conflict.

Oh, installation on Debian buster works with e.g.:

@chris.lamb that's the same issue. Could someone having this problem please run

@chris.lamb yes, I think that's the same issue. I hope to get around to look at it again later this week.

Oh and

Hi,
can you please do a