[PureOS] PureOS Phone images

Fri Aug 28 00:18:50 PDT 2020

Hi Jeremiah,
thanks for moving things over to a more persistent media!

On Thu, Aug 27, 2020 at 10:29:04PM -0400, Jeremiah C. Foster wrote:
> Hi,
> 
> [Feel free to reply on-list, I just wanted to make sure everyone saw
> this.]
> 
> 
> [Please find attached an invite to a mumble call at 16:00 CEST
> tomorrow.]
> 
> Welcome to a thread about PureOS images for our Librem 5 phone. 
> 
> Let's start with Guido who knows a thing or two about the Librem 5;
> 
> "I'd like to (slowly) start filling in enough of byzantium so we can
> build images for the phone. First candidates would be a kernel and
> flash-kernel. We currently keep the sources at 
> https://source.puri.sm/Librem5/flash-kernel and 
> https://source.puri.sm/Librem5/linux-next - i just wanted to check that
> there aren't any objections when the number of packages with patches
> increases quite a bit."
> 
> Matthias writes;
> "First of all, thank you for communicating this early :-) I have no
> fundamental objections to adding it, you would just need to target
> "byzantium" or "landing". 
> 
> - Any chance that the kernel changes would break the desktop flavor of
> PureOS? Or would that be a completely separate kernel package and not
> merged with the desktop kernel?

It's a separate kernel package at the moment. I don't intend to switch
to Debian's kernel package until we also do that in Debian itself.
If you look at page 25 here

  https://git.sigxcpu.org/cgit/talks/2020-debconf-mobile/plain/talk.pdf

you see that the diff is still a bit off but that will be improving
a lot with 5.10. Also i think we'll run newer major kernel versions
past bullseye release for some time.

> - You'd need to make sure phone things work on amd64 as well as on
> arm64 in case they have a convergent base and are used on both form
> factors. And 3) the PureOS team is tiny so we can't maintain lots and

That was the plan we discusses a while back with Jeremiah. Lots of
stuff will be adaptive with GNOME 3.38 and for GTK Sadiq worked on
making that possible:

https://source.puri.sm/Librem5/gtk/-/merge_requests/18
https://source.puri.sm/Librem5/gtk/-/issues/23

> lots of PureOS<->Debian delta. But with the phone team's help I think
> that's absolutely doable there's also secondary questions, like whether
> it makes sense to just move shared sources to the pureos group(s) in
> Gitlab also, I'll have to go through with improving Laniakea's sync
> overview page to be less cluttered - at the moment it's quite hard to
> know what needs merging where ;-) (that's actually the thing I am
> working on at the moment, since that also gets rid of the last bit of D
> code and makes deploying Laniakea easier).
> 
> - Laniakea can theoretically also build packages from Git repos -
> you'll need a list of repos and signed tags of a certain format in
> them, LK will then verify the tag signature and send the repo to a
> worker to create a source package out of that's then auto-uploaded.
> It's quite neat in concept...
> 
> ....in practice I would need to get rid of the manual list and actually
> verify signatures (at the moment anything would be built, so that's
> really not deployable)

That would be cool since i'd like to phase out the route via arm02
(which allows us to do that for the phone right now) as soon as
possible - that's also one of the reasons we don't want to allow
sloppy builds for byzantium.

Is there a public bug list for PureOS Infra/Laneakia that once could
follow to learn what's planned, has been discussed?

> Anyway, that's $future_stuff, let's work on getting the phone pieces
> into byzantium easily first :-)"
> 
> Jeremiah writes;
> - I would like to understand more about the increase in kernel patches;
> how will they be maintained? What are the expectations of the Librem 5
> team, is there going to be a transfer of responsibility for the patches
> from the Librem 5 team to PureOS team?

Kernel packages are separate - kernel maintenance will be the same as
for amber.

> Our resources are currently thinly stretched across our CI / CD, QA,
> and support teams, which means adding devices is a heavy lift that
> needs co-ordination. We don't really have a process for additional
> devices yet either and there needs to be some thought as we grow given
> that our Librem 5 traffic might significantly increase load and
> bandwidth on existing infrastructure. Do we have any data on;
> 
> - Currently Librem 5 CI (I believe we run Munin on the ARM 02 server
> no? Do we have output from that which might show load, disk, CPU, etc?

Yes. It's all rather boring load and I/O wise on arm02 since we build very
few release packages. Bigger packages (gtk, mesa, kernel) take some disk
but that's not different from what happens for amd64/arm64 right now.

> - How about the current instance of Laniakea? Are we running Munin? If
> not, do we have data on the server from a capacity planning standpoint?
> 
> - I'd like to know a bit more about the plan - do we intend to use your
> new process to build from git repos with signed tags Matthias? Or are
> we going to continue to build on ARM 02 and then upload to Laniakea?

For the 'mass switch' it would be very good to build from git via
Laneakia so save maintenance and rather use arm02 as another builder
for Laneakia (but that obviously needs Matthias involvement).

Regarding building from git let me add that we have done some
prototyping to be able to restrict packages to certain maintainers which
might be useful when we have more app contributors. I think taking the
requirements for that into account (without blocking progress) would be
good.

That said the 'where to apps go' question is one of the more interesting ones for
byzantium from my PoV since we side stepped that on amber by just using
amber-phone and requiring a review from a team member. This raises the
following questions (not necessarily for today's meeting since that
should (in my opinion) focus on getting convergent base in byzantium):

- which packaging formats do non-core apps (not necessarily maintained
  by a PureOs/L5 team member) use? We use deb now. The current ones
  are all debs https://source.puri.sm/librem5-apps and we might
  want to continue to support that.
- Where do uploads go? So will there be a byzantium-apps,
  byzantium-apps-staging and maybe the same with `-sloppy` or `-preview`
  for not yet perfect apps? (orthogonal to the packaging format)
  or should that be more like Ubuntu's PPAs (which i'm not a fan of
  for this purpose)
- In case of Debian package: how are we preventing people to upload
  a patched glibc there?
- How (and by whom) are permissions managed? (somewhat orthogonal to the
  packaging format)
- How is security support for these handled? (at least removal should be
  triggered on known CVEs) (orthogonal to the packaging format)
- what is the policy for being allowed to upload an app, how is that
  being enforced. For librem5-apps we've been basically following
  DFSG and l5 dev policy (https://storage.puri.sm/librem5/l5-policy/html/)

Since we have same apps at https://source.puri.sm/librem5-apps we could
likely use one to testdrive this.

Cheers,
 -- Guido

> 
> Best regards,
> 
> Jeremiah

> BEGIN:VCALENDAR
> VERSION:2.0
> PRODID:-//Nextcloud calendar v1.7.1
> CALSCALE:GREGORIAN
> BEGIN:VTIMEZONE
> TZID:America/New_York
> BEGIN:DAYLIGHT
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
> TZNAME:EDT
> DTSTART:19700308T020000
> RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
> END:DAYLIGHT
> BEGIN:STANDARD
> TZOFFSETFROM:-0400
> TZOFFSETTO:-0500
> TZNAME:EST
> DTSTART:19701101T020000
> RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
> END:STANDARD
> END:VTIMEZONE
> BEGIN:VEVENT
> CREATED:20200827T222327
> DTSTAMP:20200827T222327
> LAST-MODIFIED:20200827T222327
> UID:K5ZPBTM288MN1FWE1PPXJQ
> SUMMARY:PureOS Phone Images
> LOCATION:Mumble
> ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;CUTYPE=INDIVI
>  DUAL;CN=Guido Günther ;X-NC-GROUP-ID=0;SCHEDULE-STATUS=1.1:mailto:guido.g
>  unther at puri.sm
> ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;CUTYPE=INDIVI
>  DUAL;CN=Jonas Smedegaard;X-NC-GROUP-ID=1;SCHEDULE-STATUS=1.1:mailto:jonas@
>  puri.sm
> ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;CUTYPE=INDIVI
>  DUAL;CN=Adrian Alves;X-NC-GROUP-ID=2;SCHEDULE-STATUS=1.1:mailto:adrian.alv
>  es at puri.sm
> ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;CUTYPE=INDIVI
>  DUAL;CN=Nicole Faerber ;X-NC-GROUP-ID=3;SCHEDULE-STATUS=1.1:mailto:nicole.
>  faerber at puri.sm
> ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;CUTYPE=INDIVI
>  DUAL;CN=Jeremiah C. Foster ;X-NC-GROUP-ID=4:mailto:jeremiah.foster at puri.sm
> ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;CUTYPE=INDIVI
>  DUAL;CN=Matthias Klumpp;X-NC-GROUP-ID=5;SCHEDULE-STATUS=1.1:mailto:matthia
>  s.klumpp at puri.sm
> ORGANIZER;CN=Jeremiah Foster:mailto:jeremiah.foster at puri.sm
> CLASS:PUBLIC
> DESCRIPTION:Mumble call about PureOS phone images.
> STATUS:CONFIRMED
> DTSTART;TZID=America/New_York:20200828T100000
> DTEND;TZID=America/New_York:20200828T110000
> BEGIN:VALARM
> ACTION:AUDIO
> TRIGGER:-PT15M
> END:VALARM
> END:VEVENT
> END:VCALENDAR

> _______________________________________________
> PureOS-project mailing list
> PureOS-project at lists.puri.sm
> https://lists.puri.sm/listinfo/pureos-project