July 2019 - PureOS-project - Purism Mailing Lists

Bits from PureOS | Sharks!
by Jeremiah C. Foster 25 Oct '19

25 Oct '19

Hi, Summer is here on the East Coast of North America and that means another edition of Bits from PureOS. And no, I wasn't eaten by a shark last week on Cape Cod, but thanks for asking. To reiterate, the long-running topics we're responsible for are; 1. Reproducible builds 2. Supporting Pureboot and Purism hardware 3. Continuous delivery of PureOS 4. PureOS store (and application discovery) To that list I think we ought to add; 5. PureOS Security 6. Additional packages for PureOS We have already a security mailing list here: https://lists.puri.sm/listinfo/security We should likely develop a plan for its use. Other security topics perhaps ought to be discussed privately and I intend to kick off the topic with stakeholders. On the reproducible builds front you can follow the thread here; https://lists.puri.sm/pipermail/pureos-project/2019-July/000177.html What is happening is we're trying to adjust various time stamps that various tools insert into a given build. Those time stamps vary between builds (of course, because any two builds occur at different times). Lamby has patched many of the tools and I'm trying to find the right context to inform the tools that they're to use the standardised time stamp. Discussion with various folks has led us to cease maintaining PureBrowser. The reasons are pretty simple; we are investing in the GNOME ecosystem and GNOME web runs as a flatpak bringing in a bit of isolation to the browser which adds an additional layer of security. I think that we should make an announcement about this going forward in various places since there is often much discussion on browsers in our forums. Upcoming discussions on how to seed a build of PureOS for the L5 should be interesting, I plan to send out an invitation for discussing this in the next day or so. More info to come. Lastly, getting apps into PureOS needs to be better documented. I'm doing some packaging but am struggling with getting pbuilder to play nicely with my requests to pull in older versions of software. If we had clear instructions on how to build a PureOS image for pbuilder that would help me immensely. I'll reach out to folks regarding this since I'm certain that the knowledge needed is available. Also, uploads to Laniakea of certain packages are failing occasionally, something Guido has pointed out. We ought to speak with him to determine what the issues are and to smooth out the upload process. As always, feedback most welcome.

6 20

Bits frm PureOS | Buster edition
by Jeremiah C. Foster 20 Jul '19

20 Jul '19

Congratulations to all the DDs on this list for their work on Buster! Thank you! I'm sure there are many, many people out there grateful for your contribution. My next question naturally is; is PureOS Green going to continue to track Buster? This was a question we brought up in March: https://lists.puri.sm/pipermail/pureos-project/2019-March/000069.html A broader discussion followed that thread and while the shape of consensus seemed to emerge, there were some threads left dangling. Now, as we're being asked by other stakeholders what are plans are, I'd like to be able to announce that PureOS Green is tracking Debian Buster. May I make that announcement? Regards, Jeremiah

6 16

PureOS 2019/07/14 images ready for testing
by Matthias Klumpp 16 Jul '19

16 Jul '19

Hi! Primarily due to an initramfs permission issue where reading disk encryption keys from the initramfs was possible in certain configurations[1], but also because the previous images were getting old, we have new PureOS installation images for testing. Thinks to look at, as always: * Does the image boot cleanly? * Does the Live installer work? * Does the OEM installer work? * Does the OEM initial setup work as expected? * Does the respective desktop function as expected? * Any noticeable bugs/regressions? You can find the images for the respective flavors here: GNOME Live: https://downloads.puri.sm/live/gnome/2019-07-14/ GNOME OEM: https://downloads.puri.sm/oem/gnome/2019-07-14/ Plasma Live: https://downloads.puri.sm/live/plasma/2019-07-14/ I already tested the images and found no noticeable issues, but having more eyes on them before we change the default download links is always good. Happy testing! Cheers, Matthias [1]: https://calamares.io/calamares-cve-2019/

1 0

Using SOURCE_DATE_EPOCH env var in PureOS builds
by Jeremiah C. Foster 12 Jul '19

12 Jul '19

Hi, I impatiently added the SOURCE_DATE_EPOCH to the version of make-live that we use to build PureOS images. It seems to have made a difference though not completely eliminated our blockers to reproducibility; http://45.33.86.90/pureos-8.0-images.html While the byte-for-byte difference now is much smaller, and the date is consistent across builds in the ISO at least, other parts of the build are getting the date from the file system I believe. For example, under the section casper/filesystem.squashfs[0.] unsqaushfs -s {} says; 2 Creation·or·last·append·time·Fri·Jul·12·07:12:11·2019 2 Creation·or·last·append·time·Fri·Jul·12·05:11:57·2019 The leads me to believe that I need to ensure that SOURCE_DATE_EPOCH is being seen when the squashfs file system is written using Lamby's debug method of printing "echo SDE=$SOURCE_DATE_EPOCH" in various places to determine if it's being seen in each build context. After that I think the next step, or even a step to take anyway, is to run strip-nondeterminism over the resulting ISOs[1.] 0. http://45.33.86.90/pureos-8.0-images.html#casper-filesystem.squashfs 1. https://packages.debian.org/sid/strip-nondeterminism Feedback, corrections most welcome. Regards, Jeremiah

2 3

Bits from PureOS
by Jeremiah C. Foster 12 Jul '19

12 Jul '19

Hi! There's been some discussion amongst various folks that our communication culture can be suboptimal at times. I thought I would try and encourage greater use of our mailing list to compliment our chat channel and this irregular (but hopefully frequent) email is a collection of "bits" in the spirit of a Debian's "Bits from . . . " In PureOS we have a number of current topics which I'll enumerate here; 1. Reproducible builds 2. Supporting Pureboot and Purism hardware 3. Continuous delivery of PureOS 4. PureOS store (and application discovery) These are high level topics which are organized in no particular priority. I thought that I'd try to have updates in each of these areas and to tie in the work being done in other parts of Purism that may have an impact on those topics expanding the topic list where necessary. In regard to reproducible builds, Chris Lamb and I have been meeting regularly to discuss PureOS builds and their reproducibility. We've managed to create a automated scan of PureOS builds via diffoscope; http://45.33.86.90/pureos-8.0-images.html That page is created automatically each day from two builds done on that host. I believe that we'll be able to say that the PureOS ISO is reproducible when the builds are byte-for-byte identical. We hold some documentation here; https://tracker.pureos.net/w/development/reproducible_isos/ The next topic I'd like to talk about is the delta between PureOS and Debian. I mention this because I feel it fits into the Continuous Delivery topic above and is something that I've been talking to Matthias and Gunther about, albeit breifly. The reason to understand the delta between PureOS and Debian is to be able to calculate roughly the effort needed to move our currently Phone OS from Debian to PureOS. Hopefully being able to specify what is different between the two distros will enable us to create a PureOS image that matches the versions and/or the functionality of the work being done in the L5 team. I'll send a separate email regarding this topic as it is important and we may need to gather a number of people to participate. Work is ongoing on the PureOS Store. Rodolfo has been working recently on adaptive design and it looks good. More work to be done of course. I'm working on getting a round trip for Animatch and other flatpaks, like Lollypop. At this stage I'm looking to export the built flatpak to the server and see if I can't use the "install" button to install it on the devkit. More updates soon. We may have an additional colleague if the org chart is any indication, I think that will be a welcome addition. I'll let everyone know more as soon as I know more. Well, just a medium length email this time, if they get too long they tend to get a bit boring. There's still lots to write about but hopefullly another "Bits from PureOS" will be coming soon to an inbox near you. Cheers, Jeremiah

3 9

[Fwd: Suite name for security updates changing with Debian 11 "bullseye"]
by Jeremiah C. Foster 11 Jul '19

11 Jul '19

Speaking of suite name changes . . .

1 0

Re: [PureOS] "PureOS changes" notifications
by Chris Lamb 11 Jul '19

11 Jul '19

Matthias Klumpp wrote: > I didn't actually understand your mails as "I want Git notifications" > but rather as "I want notifications on archive uploads and other > archive actions", so I never actually directly asked our sysadmins for > the former. (Sure. The [sysadmin] ticket I filed has this and other details in so I felt no need to duplicate its contents here.) Best wishes, -- Chris Lamb https://puri.sm

2 1

Fresh+Stable Debian, Upstream
by Tobias Bernard 09 Jul '19

09 Jul '19

Hi all, As part of the discussions around the need for more stability in PureOS to support enterprise use cases we agreed a few months ago that ideally what we'd want is an OS that comes with a recent user-facing stack *and* a reasonable degree of stability. Currently with Debian we only have 2 choices: Follow stable and get a new user-facing platform stack every 3 years or follow testing and get it every day. Unfortunately, neither of these makes sense for consumer desktop use. Testing is too unstable, and stable is almost always way behind the current GNOME platform. We can't afford to be too far behind, because ecosystem-wide changes (e.g. the app menu migration, the new icon style, etc.) affect third party applications regardless of what version of the platform we ship. This goes for both desktop and phone. What would like is something like a yearly cycle, in sync with at least every other upstream GNOME release, similar to other consumer-facing OSes. I had a discussion with Jonas the other week, and an interesting idea we came upon about was trying to change the options we have from the Debian side, from within upstream. Debian currently doesn't have a great branch for desktop use, so commonly people run Debian testing for that, but everyone agrees that this is not ideal. It would be interesting to explore if there's enough interest in the Debian community to try and establish an additional branch between stable and testing, which matches people's expectations for a desktop system in terms of stability/freshness. Seeing as we work upstream as much as possible, it seems to me that the "Purism Way" to solve this problem would be to work with other interested parties upstream to find a solution that will be beneficial for all Debian desktop users, and of course require less maintenance for us in the long run. I know this is a complicated issue that has been discussed already in various forms in various places but we still need a solution, so here we go again :) Cheers, Tobias

2 1

Re: [PureOS] "PureOS changes" notifications
by Chris Lamb 04 Jul '19

04 Jul '19

Dear Matthias, > > Whilst the social-ish (Purism) IRC channels are helpful to some > > degree, I'm starting to feel somewhat isolated with my work on PureOS. > > Me too, a bit - we might just need more communication in general on > what we are working on, like this particular mail thread :-) I'm generally not one to send "me too" or "+1" emails, but I will get over my usual reticence that here to underline that this would be great. How can I help? Best wishes, -- Chris Lamb https://puri.sm

3 8

Re: [PureOS] PureOS | Debian delta
by Matthias Klumpp 04 Jul '19

04 Jul '19

Am Mi., 3. Juli 2019 um 16:47 Uhr schrieb Chris Lamb <chris.lamb(a)puri.sm>: > [...] > These patches should canonically be in the source.puri.sm repositories: > > https://source.puri.sm/pureos/packages > > For example, here is a patch of mine to Gimp: > > https://source.puri.sm/pureos/packages/gimp/blob/10711bb1ccbf9be950445a6a6b… > > > […] as well as the fact that we do not have a non-free repo. > > These parts of "negative space" are less obvious. Whilst you mention > the absense of the non-free repository we also have removed other > specific packages from "main". I am unsure how to canonically generate > such a list from our archive software, but it is likely possible with > some grep-dctrl foo and a quick refresher on set theory. Or by looking at the list of intentionally not-synced packages: https://master.pureos.net/synchrotron/blacklist > In addition, there is the delta in unmodified packages that we have > migrated from unstable, which additionally add to the delta from > Debian buster. This could be a refinement othe programming task > outlined in my previous paragraph if one was inclined to locate the > exact answer. > > > Knowing the delta would help us to understand how to move the work > > being done on the L5 phone into our CD system for example > > Can you elaborate on this, just out of interest? In particular, what > is specific about the CD system that I am perhaps missing? I would also be interested in that answer! Additionally to all the delta opportunities mentioned by Chris, there is also a "built-in" difference by compiling packages differently on PureOS compared to Debian. That is for example the case for gnome-software and grub which compile with different settings depending on the OS they are built on. So, finding the complete delta is a bit tricky, but definitely possible. Cheers, Matthias

2 1