- PureOS-project - Purism Mailing Lists

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

PureOS | Debian delta
by Jeremiah C. Foster 03 Jul '19

03 Jul '19

Hi, What is the PureOS < > Debian delta? I assume that it is a set of patches that we apply to packages, like the work Jonas does on Firefox ESR, as well as the fact that we do not have a non-free repo. 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. Just documenting it would be a big help. Where can I find this information? Cheers, Jeremiah

3 2

"PureOS changes" notifications
by Chris Lamb 14 Jun '19

14 Jun '19

Hi -project, Many years ago I created an IRC bot for Debian that would live on its own channel and simply notify on new uploads, bugs and similar changes in that distribution: https://chris-lamb.co.uk/projects/debian-devel-changes-bot … it is now rather popular and, indeed, many people have noted to me in the interim years not only how motivating it was to be exposed to others' work like that without having to explicitly or actively look for it but it informs & keeps them up-to-date on the project in a wider, less-technical, sense. I found it also a valuable learning tool — if I don't understand a bug report that scrolls past I sometimes click it and invariably end up learning something I didn't previously know. § In this light, I created the following ticket early last year to get this rolling for PureOS: https://tracker.pureos.net/T375 … however, movement on this appears to have stalled or otherwise is lower on others' priority lists than I believe it should be. The basic idea would be to have a separate "dev/pureos/changes" (or similarly named) Matrix room that would have this info spammed into it. Discussions would remain on dev/pureos or, of course, on issue tracker, etc. The bug itself unfortunately is a little ambiguous about what we would like to include in the notifications (tracker bugs vs uploads vs Git commits...), but I firmly and adamently believe that getting *anything* at the moment would be great start so I wasn't being overly specific by design. (The task is also being tracked in parallel on the sysadmin tasks tracker too, adding somewhat to the confusion.) Note that this would also help relieve some developers of feeling like they are the only ones who know about certain areas, preventing further potential "siloing" of knowledge. Just to underline, whilst it might appear to be a "wishlist" feature, I believe it will provide some always-needeed social cohesion and connection within the PureOS development team! As geeks we often criminally underrated such things.. we are humans too! Any thoughts? In particular, can we get some strong +1's from you all (especially Jeremiah) to take back to the ticket and hopefully parley that into getting this reprioritised? Best wishes, -- Chris Lamb https://puri.sm

2 2

Updates to tracker.pureos.net
by Jeremiah C. Foster 25 May '19

25 May '19

Hello, Today (Friday May 24th) there has been an update to the machine that runs our Phabricator instance. It has had the OS updated to Stretch (Debian 9.9). There also has been the installation of service files to start phabricator on boot. I think it might be nice to update phabricator as well the version running now is kinda old: https://tracker.pureos.net/config/version/ I'm happy to upgrade phabricator if it's simply a case of 'git pull' and then launching the apps but perhaps Matthias you know of a right way to do this? Cheers, Jeremiah

2 1

Certificate renewal and tracker.pureos.net going offline this weekend
by Jeremiah C. Foster 21 May '19

21 May '19

Hi, There are some expired certs and some general DNS cruft that admins are going to be addressing in the coming week on the tracker.pureos.net site. I mention this just as a heads-up. I hope to come back with more info once it is firmed up. Regards, Jeremiah

1 0

Re: [PureOS] Laniakea Python version is now online!
by Matthias Klumpp 21 May '19

21 May '19

Am Mo., 20. Mai 2019 um 19:44 Uhr schrieb Chris Lamb <chris.lamb(a)puri.sm>: > > Matthias Klumpp wrote: > > > > > Since last week, all of PureOS infrastructure is now switched to the > > > > latest, mostly Python-based version of Laniakea[1]. > > > > > > This is great news. Congratulations Matthias! > > Indeed, congratulations and thank you for posting about it here too. > My apologies for this late reply getting lost between various cracks > in my inbox. :( Don't worry, there is no expiry date on replies ;-) > > > If so, perhaps we use a separate Laniakea channel for Matrix so as > > > not to flood the PureOS channel. > > I completely +1 the idea of a #pureos-changes channel. > > I use this pattern in many projects; having that "soft" visibility is > extremely helpful for all sorts of reasons (both technical and non- > technical) in terms of encouraging more of a team feel, avoiding any > feeling of being isolated from others. Indeed, I even wrote the > #debian-devel- changes bot back in 2008 for these very reasons and it > has been remarkably successful in these regards. Yes, we had this in Tanglu as well and it was really useful :-) > Can I thus resubmit my request for this to be re-prioritised? :) It's definitely a high priority, but giving people access to easy information about the archive is even more important I would say. That being said, software.pureos.net is available again now, so you can view build logs easily again. Next I will also re-add the debcheck and migration information to the package details pages, as that's important as well for diagnosing problems. Then maybe also refine the pages to sort by suite as well, and also improve the application/component search a bit (as that's the neat thing our users may be interested to use, and it's easy to do). Than I would actually be moving on to reinstate the messaging system between Laniakea components, however I don't feel at ease doing that without a proper testing framework in place, so that also has a slightly higher priority. But then, the next thing definitely is the message bus, Matrix bot and possibly Fedmsg bridge. > Oh, one adjunct question; how can we contribute/learn more about this > codebase? Whilst justifiable for many reasons, as it is on Github it > definitely feels a little separate from the rest of the PureOS code. > Can we ameliorate this somehow? I don't have any concrete suggestions > at this time, alas. On why it's on a different platform: That is simply because the project started outside of PureOS before I joined Purism, and was for a while shared between two derivatives. Nowadays I actually prefer it to be not as tightly coupled to the PureOS project, because I hope that as soon as it's mature enough more derivatives may consider using it. That's very often easier when the infrastructure for a project is at a more neutral place. The README file of the project as well as some PureOS wiki pages definitely tell people who want to know who was responsible for moving the project forward though. On contributing: There is outdated documentation on https://lkorigin.github.io/ which I should update soon to reflect what the Python version has to offer (and to elaborate on some points). The code is also documented, but generating some API documentation from it would also be helpful, I guess. I also gave a talk about the project at Debconf, but that's probably not a good starting point. The talk slides however may be useful, I'd have to modernize them as well though, just like the rest of the documentation. To build the project itself, one can use - rather unusual for a Python project - Meson. Meson/ninja will build the binary parts and then install all pieces into the right location, then one can use the `lk-admin` tool to initialize the database and configure the system. Currently, to make Laniakea really useful, one needs to combine it with either dak or reprepro for archive management. I'll certainly answer any questions anyone trying to understand any of the components may have, and hopefully also write a nice quickstart guide. The problem to get all the tasks done is - as always - time ;-) Cheers, Matthias

2 1

Laniakea Python version is now online!
by Matthias Klumpp 20 May '19

20 May '19

Hello! Since last week, all of PureOS infrastructure is now switched to the latest, mostly Python-based version of Laniakea[1]. ## What is Laniakea? Laniakea is a suite of tools and adapters which originated in the Tanglu Debian derivative. Its purpose is to bring together data and configuration from the multitude of separate tools that are required to run a Debian derivative, as well as adding missing functionality in an integrated way. Tools which are wrapped by Laniakea include Britney, dose3, germinator, dak and more. Due to Laniakea's database being the authoritative source of information for a derivative, there is always only one place to change configuration, individual configuration for the wrapped tools is automatically generated from database information. Also, the centralization of data in a database and well-defined directory structure allows Laniakea modules to cross-reference information and make decisions based on data from other tools, e.g. the debcheck information is used to determine whether a package is actually buildable in the distribution. Using the database, all information Laniakea knows about is accessible (currently read-only) via modern web interfaces. Laniakea also contains a global worker pool to execute arbitrary long-running tasks. These tasks currently are image builds and package builds. All tasks are run on separate machines in systemd-nspawn containers via debspawn[2], for build tasks static-analysis reports are generated in the Firehose XML format[3]. Laniakea also contains a message-bus based on ZeroMQ and JSON to let modules running on other machines know about changes and react to events when running in a more isolated environment. This also allows notifications via email or Matrix. ## What changed now? Laniakea previously was written entirely in the D programming language. Since the project was a fun experiment in Tanglu, using the language also wasn't much of an issue. With our new requirements in PureOS and limited manpower though, it became apparent that the choice of D was hindering progress in this case, simply due of D's much smaller ecosystem of existing tools and libraries. Time spent at improving the database connection code in D could be better spent at implementing a new feature we need. So, Laniakea was mostly ported to Python 3.6+ with some code still remaining in D. Since D has great bindings to Python, writing a module to run existing D code from Python was very easy. This also allows us to reuse a lot of the more complex logic in Laniakea without changes (and the chance to introduce new bugs). Porting progress can be followed via this document[4]. Since Monday last week, PureOS' infrastructure is now running on the Python-ified version of Laniakea, removing the extra maintenance burden of developing two versions of the same software in parallel. ## How does the change affect me? Ideally, a user or developer of PureOS should not see any changes. The new implementation should work just as the previous one. The web UI on master.pureos.net looks slightly different, but that is it. Since the new Laniakea database has no indices yet, certain queries could take a bit longer. One notable change is the absence of software.pureos.net - this module could not be easily ported and needs to be rewritten entirely. I am working on that, and we will definitely get it back, better than before. The Laniakea message piblishing code also has not been ported yet, so modules can not communicate with each other via ZeroMQ. This should not ceuase any issues, but when it is finally implemented, we will get a new Matrix bot to notify about archive changes immediately. ## What's next? ### Create an integration test framework for Laniakea We need better testing, or rather, any testing for some Laniakea modules and larger pieces of the codebase. Since a large chunk of Laniakea is interfacing with existing code or with its own modules, we need some way to do intergration testing properly. ### More unit testing! The Python code doesn't have many tests written yet, so this needs to be added as well. ### Bring back software.po.n (webswview) The web application just needs to be rewritten. This is a work in progress at time. ### Reimplement Laniakea messaging The Lighthouse module of Laniakea needs to get its message publication support back. I intend to make use of signedjson[5] for message signing this time. When implementing this feature, the very crude current Lighthouse implementation also needs a complete overhaul. Additionally, we can write a Matrix bot for Laniakea again at this stage. ### Better dak integration The Debian Archive Kit (dak) and Laniakea basically exist alongside each other, not interacting all that much. That should be changed to make dak and Laniakea talk to each other better to reduce the reliance on cronjobs. ### Better performance There is a lot of potential for performance improvements in Laniakea, most notably in the module that imports archive data into the database. Making these improvements will allow for many nice things, like faster package processing. ### Package for Debian Laniakea should be available from withing Debian. This is a long-term goal as it requires at least some stability of the database schemas and more and better testing. Also, the JavaScript dependencies of the web modules need to be sorted out properly. Ultimately though, at some point you can just apt install Laniakea to create your own Debian derivative. ## What can I do? Contribute! Either by writing code for Laniakea (documentation is currently updated to reflect the Python changes) or filing bugs. If you see anything weird happening in PureOS infrastructure that hasn't happened before, please file a bug in the PureOS bugtracker[6] or against Laniakea directly if you know it is to blame already. Happy hacking! Matthias [1]: https://github.com/lkorigin/laniakea [2]: https://github.com/lkorigin/debspawn [3]: https://github.com/fedora-static-analysis/firehose [4]: https://github.com/lkorigin/laniakea/blob/master/docs/porting-status.md [5]: https://github.com/matrix-org/python-signedjson [6]: https://tracker.pureos.net/

3 3

Updates on reproducible builds in PureOS
by Jeremiah C. Foster 18 May '19

18 May '19

Hi, I've received and email recently from the folks at the FSF about PureOS reproducible builds. When we were at LibrePlanet was asked if the FSF would be kind enough to 'verify' our reproducible builds and they replied via mail saying; > Yes, we are interested in doing this. Generally, we will want > the build and verification process to be publicly documented > and mostly automated for an initial setup To which I replied, here is how we build our ISOs; https://tracker.pureos.net/w/development/howto_build/ I've set up debspawn to build in ISO from cron as well and I'll automated diffoscope to create and html report for us and the FSF to review. I also have created this document to explain a bit about reproducible builds in PureOS. This document pertains to PureOS and it refers to upstream source to find out more about the upstream project. https://tracker.pureos.net/w/development/reproducible_isos/ Currently the work being done is around automation; - having image building being done by cron - running diffoscope The ISOs that get built today are around 1.5 gigs which makes me wonder if they're too large to put in Debian's Jenkins machine lest they fill up disk. Happy to hear feedback on all the above. Regards, Jeremiah

2 1

2025

2024

2023

2022

2021

2020

2019

2018

PureOS-project