All right, hi, everyone.
I'm Ed Oliparanoid, and this is post-marketer
S reliability in 2026.
So, last year at first,
we were there too.
I gave a talk about post-marketer's in general,
how it is, how it fits into Linux mobile,
the wider ecosystem that we are building together.
And so on, if you want to know that,
please watch the first talk first.
This is a rather short arc on a specific topic.
Which is last year,
we said that our main goal for 2025 is
improve the reliability of post-marketerS.
And, yeah, improve the reliability.
So, what did we work on since last for them?
There was system D and mother upstreaming,
which gives us better management of services,
logging, and more general predictability
in the behavior of lower levels of the operating system.
We shipped that.
And now, in system D,
259, mother support is actually upstream,
which is awesome.
So, we don't need to maintain patches downstream anymore,
and this was made possible by
U of water, Jane, Casey,
and U by Anna,
Clayton, Focity, PJ, and a lot more people.
Really awesome.
Then we worked on an optional immutable version of post-marketerS,
called Uranium.
This will allow moving from one,
we tested image to another one,
so you don't have the problems that you run the package manager,
and then you screw up your system,
because something happens,
and you have our unique system afterwards.
Whereas the images are like,
this is the one image is tested,
and you move from one image to the next one.
And we are making it optional,
and we can still do everything you want,
if you are a developer,
and just want to mess around with the system.
And this is using system detooling,
so MK OSI,
system D, system D report,
and system D boot,
which fits nicely,
not that we have system D.
And yeah,
the status is that we have a working prototype by now,
so this can already be built for specific devices,
and it can be tested,
and it basically working,
but we need to scale it up,
so it works for all devices and so on.
Yeah, so there are other people to think for,
at App's Clayton,
as the Johannes,
and some more people who made this possible.
Next,
we worked on Lightly Repositories,
in 2023,
we started with one for Plasma Mobile,
which is our spirit, the current code,
that is there every night,
and then developers can run this version.
And afterwards,
last year,
we added Mesa,
and Forge,
and a desktop repository,
which starts,
more than manager,
LIPTMI,
UPUF,
LATPAC,
system D report kit,
the bus and lip camera.
And at the beginning of this year,
KDE will be added as another nightly repository,
and previous Plasma Mobile repository
will be moved there.
So there are some new scripts that work better,
and this will make use of this as well.
And we have a genomic repository also.
And I will show how this all fits together,
shortly,
but the big project that we worked on was CITron.
So you see a graph there,
because what we really want to do is run our tests on real devices,
and CITron is our project that is used by Valve,
who make all these cool games,
and steam them so on.
They use it in Mesa CI actually,
and we figured out,
it looks really nice there,
works nice,
so let's add up to for post-market OS.
And yeah,
so quickly how it works is,
you have your device under test,
which could be a phone,
any device for running post-market OS.
You have power delivery unit,
this video here,
that connects it,
and basically provides an API
that you can press the buttons automatically,
and run an image on it,
and so on.
And we connect this to our GitLab instance.
And this means whenever we change code in our GitLab,
we can run the tests on the real hardware,
and ensure that it really works,
and only then merge it.
And so yeah,
for this in May,
we got the first Salesforce that set up done.
Then two months later,
we were able to run post-market OS,
MK,
and then we ended up as the thing that we built in the drum of us.
Through this thing in QMU at first,
just to prove that the whole setup is working.
And same for the device package,
which means whenever you make a change to the device package,
in PMA port,
then it will run through the whole thing,
boot up the device in QMU,
and check if it's working as expected,
and if there are any regressions,
that we can then fix before we merge this stuff.
And then at the beginning of this year,
like two weeks ago,
we actually had the real first device there,
the OnePlus 6,
and now it is all set up that if you make a change to the OnePlus 6,
and portmarkless edge,
we run it on the real device,
we run the tests that are there,
and yeah,
we directly see if there's any important regression
that causes it to not boot or any other major problems.
And it looks like this,
so you have the pipeline here with all the stuff,
and then you have,
okay, it's running on the real device,
looks good, let's merge it.
And this was made possible by Martin Pablo,
Casey corner,
Federico F. Anosco,
Allen,
and Casey again for another part.
Yeah.
Yeah, this is one of the plus for sure.
And a big part of this is the PCB,
or Power Delivery Unit,
and the graph above.
I explained what it does,
and again corner and Federico did this,
and here's a short timeline.
They ordered the first version, second version,
and then it pretty much worked already,
and just in time before first them,
we got another one.
Just in time before first them,
we got another production batch of the zero three version,
and now it's here,
so I think you can see it at the stand,
if you're lucky,
and we will play around with this for sure,
at the hackathon that we have after first them.
So it looks like this,
and people are really excited about this online.
Yeah, so please don't do anything weird with it.
Yeah.
Nice.
Okay.
So what can we do with all these nice parts?
We have post-marketers,
change requests, PMCR,
and progress about redefining the main category of devices.
So we have main community and testing categories,
and main is currently mostly empty,
except for QMU,
because we realize that the staff in main isn't really working that well,
and we want to make it so that if something is in main,
then it really means that the device is really good.
And it's still in discussion,
but one thing we basically figured out is
okay, we want to require automated hardware testing for anything
that is going to be in a new main category.
Furthermore, we need automated test farms.
We already have two hacker spaces that are working towards having this,
and also look at who just gave a talk before me,
planned to set one up at Fairphone as its own project.
Yeah, also we need to add volume or test,
so right now we have basically a few tests that ensure it boots,
and so on, but as we can test everything under the sun,
basically.
One example that Fedoriko made is testing voice over IP, voice over Wi-Fi.
Yeah, that's a whole blockpost about it,
go read it if you're interested.
It just tests that the staff works,
and even tests that audio is working properly,
and so on and having this will already make sure that we don't have any regression
there, and as we all know, call audio,
it's something we want to have reliably.
Yeah, that's the go right.
So also we want to test more versions.
What we already have is test much requests,
then we can test the nightly repository which I mentioned before,
so we can, for example, test the nightly motor manager version,
and see if we have a new regression stare,
and then fix it upstream directly.
We could test current edge and stable releases,
and the random images, the immutable stuff.
And also by having this stuff,
we could have nice graphs that show us,
okay, it worked reliably over time,
and then maybe it dipped somewhere because there was a bug,
but it was followed up upon, and it was fixed right after,
and notes good again.
That's the idea, basically, where we want to go.
Expect more news soon.
We have a blog.
We have a master done account,
check that out, get involved.
We have a specific chat about the hardware CI now,
that you can join in ISC metrics,
and if you want to contribute to postmark address in any other way,
we have a lot of things that you can do,
get in just checked out the homepage, it's linked there.
And of course, we have a stand in building UD level 2,
where we have stickers and demos also.
Speakers from today.
I want to thank the postmark address team,
and in general, all contributors,
everyone working at Apple and Linux,
and Peter from LinMorp, and so on,
and I'm there for some grand stuff,
and everybody who donates to postmark address.
And of course, you're for listening.