Last month, I traveled to Kenya to attend a conference called State of the Map 2024 ( SotM for short), which is an annual meetup of OpenStreetMap contributors from all over the world. It was held at the University of Nairobi Towers in Nairobi, from the 6th to the 8th of September.
University of Nairobi.
I have been contributing to OpenStreetMap for the last three years, and this conference seemed like a great opportunity to network with others in the community. As soon as I came across the travel grant announcement, I jumped in and filled the form immediately. I was elated when I was selected for the grant and couldn t wait to attend. The grant had an upper limit of 1200 and covered food, accommodation, travel and miscellaneous expenses such as visa fee.
Pre-travel tasks included obtaining Kenya s eTA and getting a yellow fever vaccine. Before the conference, Mikko from the Humanitarian OpenStreetMap Team introduced me to Rabina and Pragya from Nepal, Ibtehal from Bangladesh, and Sajeevini from Sri Lanka. We all booked the Nairobi Transit Hotel, which was within walking distance of the conference venue. Pragya, Rabina, and I traveled together from Delhi to Nairobi, while Ibtehal was my roommate in the hotel.
Our group at the conference.
The venue, University of Nairobi Towers, was a tall building and the conference was held on the fourth, fifth and sixth floors. The open area on the fifth floor of the building had a nice view of Nairobi s skyline and was a perfect spot for taking pictures. Interestingly, the university had a wing dedicated to Mahatma Gandhi, who is regarded in India as the Father of the Nation.
View of Nairobi's skyline from the open area on the fifth floor.
A library in Mahatma Gandhi wing of the University of Nairobi.
The diversity of the participants was mind-blowing, with people coming from a whopping 54 countries. I was surprised to notice that I was the only participant traveling from India, despite India having a large OpenStreetMap community. That said, there were two other Indian participants who traveled from other countries. I finally got to meet Arnalie (from the Phillipines) and Letwin (from Zimbabwe), both of whom I had only met online before. I had met Anisa (from Albania) earlier during DebConf 2023. But I missed Mikko and Honey from the Humanitarian OpenStreetMap Team, whom I knew from the Open Mapping Guru program.
I learned about the extent of OSM use through Pragya and Rabina s talk; about the logistics of running the OSM Board, in the OSMF (OpenStreetMap Foundation) session; about the Youth Mappers from Sajeevini, about the OSM activities in Malawi from Priscilla Kapolo, and about mapping in Zimbabwe from Letwin. However, I missed Ibtehal s lightning session. The ratio of women speakers and participants at the conference was impressive, and I hope we can get such gender representation in our Delhi/NCR mapping parties.
One of the conference halls where talks took place.
Outside of talks, the conference also had lunch and snack breaks, giving ample time for networking with others. In the food department, there were many options for a lacto-ovo vegetarian like myself, including potatoes, rice, beans, chips etc. I found out that the milk tea in Kenya (referred to as white tea ) is usually not as strong compared to India, so I switched to coffee (which is also called white coffee when taken with milk). The food wasn t spicy, but I can t complain :) Fruit juices served as a nice addition to lunch.
One of the lunch meals served during the conference.
At the end of the second day of the conference, there was a surprise in store for us a bus ride to the Bao Box restaurant. The ride gave us the experience of a typical Kenyan matatu (privately-owned minibuses used as share taxis), complete with loud rap music. I remember one of the songs being Kraff s Nursery Rhymes. That day, I was wearing an original Kenyan cricket jersey - one that belonged to Dominic Wesonga, who represented Kenya in four ODIs. This confused Priscilla Kapolo, who asked if I was from Kenya! Anyway, while it served as a good conversation starter, it didn t attract as much attention as I expected :) I had some pizza and chips there, and later some drinks with Ibtehal. After the party, Piyush went with us to our hotel and we played a few games of UNO.
Minibus which took us from the university to Bao Box restaurant.
This minibus in the picture gave a sense of a real matatu.
I am grateful to the organizers Laura and Dorothea for introducing me to Nikhil when I was searching for a companion for my post-conference trip. Nikhil was one of the aforementioned Indian participants, and a wildlife lover. We had some nice conversations; he wanted to go to the Masai Maara Natural Reserve, but it was too expensive for me. In addition, all the safaris were multi-day affairs, and I wasn t keen on being around wildlife for that long. Eventually I chose to go my own way, exploring the coastal side and visiting Mombasa.
While most of the work regarding the conference was done using free software (including the reimbursement form and Mastodon announcements), I was disappointed by the use of WhatsApp for coordination with the participants. I don t use WhatsApp and so was left out. WhatsApp is proprietary software (they do not provide the source code) and users don t control it. It is common to highlight that OpenStreetMap is controlled by users and the community, rather than a company - this should apply to WhatsApp as well.
My suggestion is to use XMPP, which shares similar principles with OpenStreetMap, as it is privacy-respecting, controlled by users, and powered by free software. I understand the concern that there might not be many participants using XMPP already. Although it is a good idea to onboard people to free software like XMPP, we can also create a Matrix group, and bridge it with both the XMPP group and the Telegram group. In fact, using Matrix and bridging it with Telegram is how I communicated with the South Asian participants. While it s not ideal - as Telegram s servers are proprietary and centralized - but it s certainly much better than creating a WhatsApp-only group. The setup can be bridged with IRC as well. On the other hand, self-hosted mailing lists for participants is also a good idea.
Finally, I would like to thank SotM for the generous grant, enabling me to attend this conference, meet the diverse community behind OSM and visit the beautiful country of Kenya. Stay tuned for the blog post on Kenya trip.
Thanks to Sahilister, Contrapunctus, Snehal and Badri for reviewing the draft of this blog post before publishing.
Hey everyone!
The 2024 Linux Display Next
hackfest concluded
in May, and its outcomes continue to shape the Linux Display stack. Igalia
hosted this year s event in A Coru a, Spain, bringing together leading experts
in the field. Samuel Iglesias and I
organized this year s edition and this blog post summarizes the experience and
its fruits.
One of the highlights of this year s hackfest was the wide range of backgrounds
represented by our 40 participants (both on-site and remotely). Developers and
experts from various companies and open-source projects came together to
advance the Linux Display ecosystem. You can find the list of participants
here.
The event covered a broad spectrum of topics affecting the development of Linux
projects, user experiences, and the future of display technologies on Linux.
From cutting-edge topics to long-term discussions, you can check the event
agenda
here.
Organization Highlights
The hackfest was marked by in-depth discussions and knowledge sharing among
Linux contributors, making everyone inspired, informed, and connected to the
community. Building on feedback from the previous year, we refined the
unconference format to enhance participant preparation and engagement.
Structured Agenda and Timeboxes: Each session had a defined scope, time
limit (1h20 or 2h10), and began with an introductory talk on the topic.
Participant-Led Discussions: We pre-selected in-person participants to
lead discussions, allowing them to prepare introductions, resources, and
scope.
Transparent Scheduling: The schedule was shared in advance as GitHub
issues, encouraging participants to review and prepare for sessions of
interest.
Engaging Sessions: The hackfest featured a variety of topics, including
presentations and discussions on how participants were addressing specific
subjects within their companies.
No Breakout Rooms, No Overlaps: All participants chose to attend all
sessions, eliminating the need for separate breakout rooms. We also adapted
run-time schedule to keep everybody involved in the same topics.
Real-time Updates: We provided notifications and updates through
dedicated emails and the event matrix room.
Strengthening Community Connections: The hackfest offered ample
opportunities for networking among attendees.
Social Events: Igalia sponsored coffee breaks, lunches, and a dinner at
a local restaurant.
Museum Visit: Participants enjoyed a sponsored visit to the Museum of
Estrela Galicia Beer (MEGA).
Fruitful Discussions and Follow-up
The structured agenda and breaks allowed us to cover multiple topics during the
hackfest. These discussions have led to new display feature development and
improvements, as evidenced by patches, merge requests, and implementations in
project repositories and mailing lists.
With the KMS color management API taking shape, we discussed refinements and
best approaches to cover the variety of color pipeline from different
hardware-vendors. We are also investigating techniques for a performant
SDR<->HDR content reproduction and reducing latency and power consumption when
using the color blocks of the hardware.
Color Management/HDR
Color Management and HDR continued to be the hottest topic of the hackfest. We
had three sessions dedicated to discuss Color and HDR across Linux Display
stack layers.
Color/HDR (Kernel-Level)
Harry Wentland (AMD) led this session.
Here, kernel Developers shared the Color Management pipeline of AMD, Intel and
NVidia. We counted with diagrams and explanations from HW-vendors developers
that discussed differences, constraints and paths to fit them into the KMS
generic color management properties such as advertising modeset needs,
IN\_FORMAT, segmented LUTs,
interpolation types, etc. Developers from Qualcomm and ARM also added
information regarding their hardware.
Upstream work related to this session:
Color/HDR (Compositor-Level)
Sebastian Wick (RedHat) led this session.
It started with Sebastian s presentation covering Wayland color protocols and
compositor implementation. Also, an explanation of APIs provided by Wayland and
how they can be used to achieve better color management for applications and
discussions around ICC profiles and color representation metadata. There was
also an intensive Q&A about LittleCMS with Marti Maria.
Upstream work related to this session:
Color/HDR (Use Cases and Testing)
Christopher Cameron (Google) and Melissa Wen (Igalia) led this session.
In contrast to the other sessions, here we focused less on implementation and
more on brainstorming and reflections of real-world SDR and HDR transformations
(use and validation) and gainmaps. Christopher gave a nice presentation
explaining HDR gainmap images and how we should think of HDR. This presentation
and Q&A were important to put participants at the same page of how to
transition between SDR and HDR and somehow emulating HDR.
We also discussed on the usage of a kernel background color property.
Finally, we discussed a bit about
Chamelium
and the future of VKMS (future work and maintainership).
Power Savings vs Color/Latency
Mario Limonciello (AMD) led this session.
Mario gave an introductory presentation about AMD ABM (adaptive backlight
management) that is similar to Intel DPST. After some discussions, we agreed on
exposing a kernel property for power saving policy. This work was already
merged on kernel and the userspace support is under development.
Upstream work related to this session:
Strategy for video and gaming use-cases
Leo Li (AMD) led this session.
Miguel Casas (Google) started this session with a presentation of Overlays in
Chrome/OS Video, explaining the main goal of power saving by switching off GPU
for accelerated compositing and the challenges of different colorspace/HDR for
video on Linux.
Then Leo Li presented different strategies for video and gaming and we
discussed the userspace need of more detailed feedback mechanisms to understand
failures when offloading. Also, creating a debugFS interface came up as a tool
for debugging and analysis.
Real-time scheduling and async KMS API
Xaver Hugl (KDE/BlueSystems) led this session.
Compositor developers have exposed some issues with doing real-time scheduling
and async page flips. One is that the Kernel limits the lifetime of realtime
threads and if a modeset takes too long, the thread will be killed and thus the
compositor as well. Also, simple page flips take longer than expected and
drivers should optimize them.
Another issue is the lack of feedback to compositors about hardware programming
time and commit deadlines (the lastest possible time to commit). This is
difficult to predict from drivers, since it varies greatly with the type of
properties. For example, color management updates take much longer.
In this regard, we discusssed implementing a hw_done callback to timestamp
when the hardware programming of the last atomic commit is complete. Also an
API to pre-program color pipeline in a kind of A/B scheme. It may not be
supported by all drivers, but might be useful in different ways.
VRR/Frame Limit, Display Mux, Display Control, and more and beer
We also had sessions to discuss a new KMS API to mitigate headaches on VRR
and Frame Limit as different brightness level at different refresh rates,
abrupt changes of refresh rates, low frame rate compensation (LFC) and precise
timing in VRR more.
On Display Control we discussed features missing in the current KMS
interface for HDR mode, atomic backlight settings, source-based tone mapping,
etc. We also discussed the need of a place where compositor developers can post
TODOs to be developed by KMS people.
The Content-adaptive Scaling and Sharpening session focused on sharpening
and scaling filters. In the Display Mux session, we discussed proposals to
expose the capability of dynamic mux switching display signal between discrete
and integrated GPUs.
In the last session of the 2024 Display Next Hackfest, participants
representing different compositors summarized current and future work and built
a Linux Display wish list , which includes: improvements to VTTY and HDR
switching, better dmabuf API for multi-GPU support, definition of tone mapping,
blending and scaling sematics, and wayland protocols for advertising to clients
which colorspaces are supported.
We closed this session with a status update on feature development by
compositors, including but not limited to: plane offloading (from libcamera to
output) / HDR video offloading (dma-heaps) / plane-based scrolling for web
pages, color management / HDR / ICC profiles support, addressing issues such as
flickering when color primaries don t match, etc.
After three days of intensive discussions, all in-person participants went to a
guided tour at the Museum of Extrela Galicia beer (MEGA), pouring and tasting
the most famous local beer.
Feedback and Future Directions
Participants provided valuable feedback on the hackfest, including suggestions
for future improvements.
Schedule and Break-time Setup: Having a pre-defined agenda and schedule
provided a better balance between long discussions and mental refreshments,
preventing the fatigue caused by endless discussions.
Action Points: Some participants recommended explicitly asking for action
points at the end of each session and assigning people to follow-up tasks.
Remote Participation: Remote attendees appreciated the inclusive setup
and opportunities to actively participate in discussions.
Technical Challenges: There were bandwidth and video streaming issues
during some sessions due to the large number of participants.
Thank you for joining the 2024 Display Next Hackfest
We can t help but thank the 40 participants, who engaged in-person or virtually
on relevant discussions, for a collaborative evolution of the Linux display
stack and for building an insightful agenda.
A big thank you to the leaders and presenters of the nine sessions: Christopher
Cameron (Google), Harry Wentland (AMD), Leo Li (AMD), Mario Limoncello (AMD),
Sebastian Wick (RedHat) and Xaver Hugl (KDE/BlueSystems) for the effort in
preparing the sessions, explaining the topic and guiding discussions. My
acknowledge to the others in-person participants that made such an effort to
travel to A Coru a: Alex Goins (NVIDIA), David Turner (Raspberry Pi), Georges
Stavracas (Igalia), Joan Torres (SUSE), Liviu Dudau (Arm), Louis Chauvet
(Bootlin), Robert Mader (Collabora), Tian Mengge (GravityXR), Victor Jaquez
(Igalia) and Victoria Brekenfeld (System76). It was and awesome opportunity to
meet you and chat face-to-face.
Finally, thanks virtual participants who couldn t make it in person but
organized their days to actively participate in each discussion, adding
different perspectives and valuable inputs even remotely: Abhinav Kumar
(Qualcomm), Chaitanya Borah (Intel), Christopher Braga (Qualcomm), Dor Askayo
(Red Hat), Jiri Koten (RedHat), Jonas dahl (Red Hat), Leandro Ribeiro
(Collabora), Marti Maria (Little CMS), Marijn Suijten, Mario Kleiner, Martin
Stransky (Red Hat), Michel D nzer (Red Hat), Miguel Casas-Sanchez (Google),
Mitulkumar Golani (Intel), Naveen Kumar (Intel), Niels De Graef (Red Hat),
Pekka Paalanen (Collabora), Pichika Uday Kiran (AMD), Shashank Sharma (AMD),
Sriharsha PV (AMD), Simon Ser, Uma Shankar (Intel) and Vikas Korjani (AMD).
We look forward to another successful Display Next hackfest, continuing to
drive innovation and improvement in the Linux display ecosystem!
Hey everyone!
The 2024 Linux Display Next
hackfest concluded
in May, and its outcomes continue to shape the Linux Display stack. Igalia
hosted this year s event in A Coru a, Spain, bringing together leading experts
in the field. Samuel Iglesias and I
organized this year s edition and this blog post summarizes the experience and
its fruits.
One of the highlights of this year s hackfest was the wide range of backgrounds
represented by our 40 participants (both on-site and remotely). Developers and
experts from various companies and open-source projects came together to
advance the Linux Display ecosystem. You can find the list of participants
here.
The event covered a broad spectrum of topics affecting the development of Linux
projects, user experiences, and the future of display technologies on Linux.
From cutting-edge topics to long-term discussions, you can check the event
agenda
here.
Organization Highlights
The hackfest was marked by in-depth discussions and knowledge sharing among
Linux contributors, making everyone inspired, informed, and connected to the
community. Building on feedback from the previous year, we refined the
unconference format to enhance participant preparation and engagement.
Structured Agenda and Timeboxes: Each session had a defined scope, time
limit (1h20 or 2h10), and began with an introductory talk on the topic.
Participant-Led Discussions: We pre-selected in-person participants to
lead discussions, allowing them to prepare introductions, resources, and
scope.
Transparent Scheduling: The schedule was shared in advance as GitHub
issues, encouraging participants to review and prepare for sessions of
interest.
Engaging Sessions: The hackfest featured a variety of topics, including
presentations and discussions on how participants were addressing specific
subjects within their companies.
No Breakout Rooms, No Overlaps: All participants chose to attend all
sessions, eliminating the need for separate breakout rooms. We also adapted
run-time schedule to keep everybody involved in the same topics.
Real-time Updates: We provided notifications and updates through
dedicated emails and the event matrix room.
Strengthening Community Connections: The hackfest offered ample
opportunities for networking among attendees.
Social Events: Igalia sponsored coffee breaks, lunches, and a dinner at
a local restaurant.
Museum Visit: Participants enjoyed a sponsored visit to the Museum of
Estrela Galicia Beer (MEGA).
Fruitful Discussions and Follow-up
The structured agenda and breaks allowed us to cover multiple topics during the
hackfest. These discussions have led to new display feature development and
improvements, as evidenced by patches, merge requests, and implementations in
project repositories and mailing lists.
With the KMS color management API taking shape, we discussed refinements and
best approaches to cover the variety of color pipeline from different
hardware-vendors. We are also investigating techniques for a performant
SDR<->HDR content reproduction and reducing latency and power consumption when
using the color blocks of the hardware.
Color Management/HDR
Color Management and HDR continued to be the hottest topic of the hackfest. We
had three sessions dedicated to discuss Color and HDR across Linux Display
stack layers.
Color/HDR (Kernel-Level)
Harry Wentland (AMD) led this session.
Here, kernel Developers shared the Color Management pipeline of AMD, Intel and
NVidia. We counted with diagrams and explanations from HW-vendors developers
that discussed differences, constraints and paths to fit them into the KMS
generic color management properties such as advertising modeset needs,
IN\_FORMAT, segmented LUTs,
interpolation types, etc. Developers from Qualcomm and ARM also added
information regarding their hardware.
Upstream work related to this session:
Color/HDR (Compositor-Level)
Sebastian Wick (RedHat) led this session.
It started with Sebastian s presentation covering Wayland color protocols and
compositor implementation. Also, an explanation of APIs provided by Wayland and
how they can be used to achieve better color management for applications and
discussions around ICC profiles and color representation metadata. There was
also an intensive Q&A about LittleCMS with Marti Maria.
Upstream work related to this session:
Color/HDR (Use Cases and Testing)
Christopher Cameron (Google) and Melissa Wen (Igalia) led this session.
In contrast to the other sessions, here we focused less on implementation and
more on brainstorming and reflections of real-world SDR and HDR transformations
(use and validation) and gainmaps. Christopher gave a nice presentation
explaining HDR gainmap images and how we should think of HDR. This presentation
and Q&A were important to put participants at the same page of how to
transition between SDR and HDR and somehow emulating HDR.
We also discussed on the usage of a kernel background color property.
Finally, we discussed a bit about
Chamelium
and the future of VKMS (future work and maintainership).
Power Savings vs Color/Latency
Mario Limonciello (AMD) led this session.
Mario gave an introductory presentation about AMD ABM (adaptive backlight
management) that is similar to Intel DPST. After some discussions, we agreed on
exposing a kernel property for power saving policy. This work was already
merged on kernel and the userspace support is under development.
Upstream work related to this session:
Strategy for video and gaming use-cases
Leo Li (AMD) led this session.
Miguel Casas (Google) started this session with a presentation of Overlays in
Chrome/OS Video, explaining the main goal of power saving by switching off GPU
for accelerated compositing and the challenges of different colorspace/HDR for
video on Linux.
Then Leo Li presented different strategies for video and gaming and we
discussed the userspace need of more detailed feedback mechanisms to understand
failures when offloading. Also, creating a debugFS interface came up as a tool
for debugging and analysis.
Real-time scheduling and async KMS API
Xaver Hugl (KDE/BlueSystems) led this session.
Compositor developers have exposed some issues with doing real-time scheduling
and async page flips. One is that the Kernel limits the lifetime of realtime
threads and if a modeset takes too long, the thread will be killed and thus the
compositor as well. Also, simple page flips take longer than expected and
drivers should optimize them.
Another issue is the lack of feedback to compositors about hardware programming
time and commit deadlines (the lastest possible time to commit). This is
difficult to predict from drivers, since it varies greatly with the type of
properties. For example, color management updates take much longer.
In this regard, we discusssed implementing a hw_done callback to timestamp
when the hardware programming of the last atomic commit is complete. Also an
API to pre-program color pipeline in a kind of A/B scheme. It may not be
supported by all drivers, but might be useful in different ways.
VRR/Frame Limit, Display Mux, Display Control, and more and beer
We also had sessions to discuss a new KMS API to mitigate headaches on VRR
and Frame Limit as different brightness level at different refresh rates,
abrupt changes of refresh rates, low frame rate compensation (LFC) and precise
timing in VRR more.
On Display Control we discussed features missing in the current KMS
interface for HDR mode, atomic backlight settings, source-based tone mapping,
etc. We also discussed the need of a place where compositor developers can post
TODOs to be developed by KMS people.
The Content-adaptive Scaling and Sharpening session focused on sharpening
and scaling filters. In the Display Mux session, we discussed proposals to
expose the capability of dynamic mux switching display signal between discrete
and integrated GPUs.
In the last session of the 2024 Display Next Hackfest, participants
representing different compositors summarized current and future work and built
a Linux Display wish list , which includes: improvements to VTTY and HDR
switching, better dmabuf API for multi-GPU support, definition of tone mapping,
blending and scaling sematics, and wayland protocols for advertising to clients
which colorspaces are supported.
We closed this session with a status update on feature development by
compositors, including but not limited to: plane offloading (from libcamera to
output) / HDR video offloading (dma-heaps) / plane-based scrolling for web
pages, color management / HDR / ICC profiles support, addressing issues such as
flickering when color primaries don t match, etc.
After three days of intensive discussions, all in-person participants went to a
guided tour at the Museum of Extrela Galicia beer (MEGA), pouring and tasting
the most famous local beer.
Feedback and Future Directions
Participants provided valuable feedback on the hackfest, including suggestions
for future improvements.
Schedule and Break-time Setup: Having a pre-defined agenda and schedule
provided a better balance between long discussions and mental refreshments,
preventing the fatigue caused by endless discussions.
Action Points: Some participants recommended explicitly asking for action
points at the end of each session and assigning people to follow-up tasks.
Remote Participation: Remote attendees appreciated the inclusive setup
and opportunities to actively participate in discussions.
Technical Challenges: There were bandwidth and video streaming issues
during some sessions due to the large number of participants.
Thank you for joining the 2024 Display Next Hackfest
We can t help but thank the 40 participants, who engaged in-person or virtually
on relevant discussions, for a collaborative evolution of the Linux display
stack and for building an insightful agenda.
A big thank you to the leaders and presenters of the nine sessions: Christopher
Cameron (Google), Harry Wentland (AMD), Leo Li (AMD), Mario Limoncello (AMD),
Sebastian Wick (RedHat) and Xaver Hugl (KDE/BlueSystems) for the effort in
preparing the sessions, explaining the topic and guiding discussions. My
acknowledge to the others in-person participants that made such an effort to
travel to A Coru a: Alex Goins (NVIDIA), David Turner (Raspberry Pi), Georges
Stavracas (Igalia), Joan Torres (SUSE), Liviu Dudau (Arm), Louis Chauvet
(Bootlin), Robert Mader (Collabora), Tian Mengge (GravityXR), Victor Jaquez
(Igalia) and Victoria Brekenfeld (System76). It was and awesome opportunity to
meet you and chat face-to-face.
Finally, thanks virtual participants who couldn t make it in person but
organized their days to actively participate in each discussion, adding
different perspectives and valuable inputs even remotely: Abhinav Kumar
(Qualcomm), Chaitanya Borah (Intel), Christopher Braga (Qualcomm), Dor Askayo,
Jiri Koten (RedHat), Jonas dahl (Red Hat), Leandro Ribeiro
(Collabora), Marti Maria (Little CMS), Marijn Suijten, Mario Kleiner, Martin
Stransky (Red Hat), Michel D nzer (Red Hat), Miguel Casas-Sanchez (Google),
Mitulkumar Golani (Intel), Naveen Kumar (Intel), Niels De Graef (Red Hat),
Pekka Paalanen (Collabora), Pichika Uday Kiran (AMD), Shashank Sharma (AMD),
Sriharsha PV (AMD), Simon Ser, Uma Shankar (Intel) and Vikas Korjani (AMD).
We look forward to another successful Display Next hackfest, continuing to
drive innovation and improvement in the Linux display ecosystem!
Several people have been asking me to explain and/or write about my
solution for chatting nowadays. I realize that the current scenario
is much more complex than, say, 10 or 20 years ago. Back then, this
post would probably be more about the IRC client I used than about
different chatting technologies.
I have also spent a non trivial amount of time setting things up the
way I want, so I understand that it s about time to write about my
setup not only because I think it can be helpful to others, but also
because I would like to document things for myself.
The backbone: Matrix
I chose to use Matrix as the place where I integrate everything.
Despite there being some heavy (and justified) criticism on the
protocol itself, it serves me well for what I need right now.
Obviously, I don t like the fact that I have to provide Matrix and all
of its accompanying bridges a VPS with 4GB of RAM and 3 vCPUs, but I
think that that ship has sailed, unfortunately.
In an ideal world, I would be using XMPP and dedicating only a
fraction of the resources I m using today to have a full chat system.
And since I have been running my personal XMPP server for more than a
decade now, I did try to find a solution that would allow me to keep
using it, but unfortunately the protocol became almost a hobbyist
thing, so there s that.
A few disclaimers
I self-host everything, including my Matrix server. Much of what I
did won t work if you don t self-host Matrix, so keep that in mind.
This won t be a post teaching you how to deploy the services. My
intention is to describe what I use and for what purpose.
Also, as much as I try to use Debian packages for everything I do, I
opted to deploy all services using a community-maintained Ansible
playbook which is very well written and organized:
matrix-docker-ansible-deploy.
Last but not least, as I said above, you will likely need a machine
with a good amount of RAM, CPU and storage, especially if you deploy
Synapse as your Matrix homeserver (which is what I recommend if you
plan to use the bridges I ll mention). My current VPS has 4GB of RAM,
3 vCPUs and 80GB of storage (of which I m currently using
approximately 55GB).
Problem #1: my Matrix client(s)
There are a lot of clients that can talk the Matrix protocol, but most
of them are either web clients or GUI programs. I live on the
terminal, more specifically inside Emacs, so I settled for the amazing
ement.el Emacs mode. It works surprisingly well, but unfortunately
doesn t support end-to-end encryption out of the box; for that, you
have to hook it up with pantalaimon. Unfortunately, the project seems
abandoned and therefore I don t recommend you to use it. I don t use
it myself.
When I have to reply some E2E encrypted message from another user, I
go to my web browser and use my self-hosted Element client. It s a
nuisance, but one that I m willing to accept because of security
concerns.
If you re into web clients and don t want to use Element (because it
is heavy), you can try Cinny. It s lightweight and supports a decent
set of features.
If you re a terminal lover but don t use Emacs, you may want to try
gomuks or iamb.
Problem #2: IRC bridging
There are basically two types of IRC bridges for Matrix:
The regular and most used matrix-appservice-irc. This bridge takes
Matrix to IRC (think of IRC users with the [m] suffix appended to
their nicknames), and is what the matrix.org and other big
homeservers (including matrix.debian.social) use. It s a complex
service which allows thousands of Matrix users to connect to IRC
networks, but that unfortunately has complex problems and is only
worth using if you intend to host a community server.
A bouncer-like bridge called Heisenbridge. This is what I use
personally. It takes IRC to Matrix, which means that people on
IRC will not know that you re using Matrix. This bridge is much
simpler, and because it acts like a bouncer it s pretty much
impossible for it to cause problems with the IRC network.
Due to the fact that I sometimes like to use other IRC clients, I
still run a regular ZNC bouncer, and I use Heisenbridge to connect to
my ZNC. This means that I can use, e.g., ERC inside Emacs and my
Matrix bridge at the same time. But you don t necessarily need to run
another bouncer; you can simply use Heisenbridge and connect directly
to the IRC network(s) you want.
A word of caution, though: unlike ZNC, Heisenbridge doesn t support
per-user configuration when you use it in bouncer mode. This is the
reason why you need to self-host it, and why it s not possible to
offer the service to other users (they would have access to your IRC
network configuration otherwise).
It s also worth talking about logs. I find that keeping logs of
everything that goes on IRC has saved me a bunch of times, and so I
find it really important to continue doing that. Unfortunately,
neither ement.el nor Element support logging things out of the box
(at least not that I know). This is also one of the reasons why I
still keep my ZNC around: I configure it to log everything.
Problem #3: Telegram
I don t use Telegram myself, but unfortunately several people from the
Debian community do, especially in Brazil. There is a whole Debian
community on Telegram, and I wanted to be able to bridge our Debian
Matrix channels to their Telegram counterparts.
I am currently using mautrix-telegram for that, and it s working
great. You need someone with a Telegram account to configure their
credentials so that the bridge can connect to it, but afterwards it s
really easy to bridge channels together.
Problem #4: GitLab webhooks
Something else I wanted to be able to do was to receive notifications
regarding new issues, merge requests and other activities from Salsa.
For this, I m using maubot, which is awesome and has a
huge list of plugins. I m using the gitlab one.
Final thoughts
Overall, I m satisfied with the setup I have now. It has certainly
taken some time and effort to find the right tool for each problem I
needed to solve, and I still feel like there are some rough edges to
soften (like the fact that my Emacs client doesn t support E2E
encryption out of the box, or the whole logging situation), but
otherwise things are working fine and I haven t had any big problems
with the deployment. You do have to be much more careful about stuff
(for example, when I installed an unrelated service that hijacked my
Apache configuration and made Matrix s federation silently stop
working), though.
If you have more specific questions about any part of my setup, shoot
me an email and I ll do my best to help.
Happy chatting!
Beer, cake and ISO testing amidst rugby and jazz band chaos
On Saturday, the Debian South Africa team got together in Cape Town to celebrate Debian s 31st birthday and to perform ISO testing for the Debian 11.11 and 12.7 point releases.
We ran out of time to organise a fancy printed cake like we had last year, but our improvisation worked out just fine!
We thought that we had allotted plenty of time for all of our activities for the day, and that there would be plenty of time for everything including training, but the day zipped by really fast. We hired a venue at a brewery, which is usually really nice because they have an isolated area with lots of space and a big TV nice for presentations, demos, etc. But on this day, there was a big rugby match between South Africa and New Zealand, and as it got closer to the game, the place just got louder and louder (especially as a band started practicing and doing sound tests for their performance for that evening) and it turned out our space was also double-booked later in the afternoon, so we had to relocate.
Even amidst all the chaos, we ended up having a very productive day and we even managed to have some fun!
Four people from our local team performed ISO testing for the very first time, and in total we covered 44 test cases locally. Most of the other testers were the usual crowd in the UK, we also did a brief video call with them, but it was dinner time for them so we had to keep it short. Next time we ll probably have some party line open that any tester can also join.
Logo
We went through some more iterations of our local team logo that Tammy has been working on. They re turning out very nice and have been in progress for more than a year, I guess like most things Debian, it will be ready when it s ready!
Debian 11.11 and Debian 12.7 released, and looking ahead towards Debian 13
Both point releases tested just fine and was released later in the evening. I m very glad that we managed to be useful and reduce total testing time and that we managed to cover all the test cases in the end.
A bunch of things we really wanted to fix by the time Debian 12 launched are now finally fixed in 12.7. There s still a few minor annoyances, but over all, Debian 13 (trixie) is looking even better than Debian 12 was around this time in the release cycle.
Freeze dates for trixie has not yet been announced, I hope that the release team announces those sooner rather than later, also KDE Plasma 6 hasn t yet made its way into unstable, I ve seen quite a number of people ask about this online, so hopefully that works out.
And by the way, the desktop artwork submissions for trixie ends in two weeks! More information about that is available on the Debian wiki if you re interested in making a contribution. There are already 4 great proposals.
Debian Local Groups
Organising local events for Debian is probably easier than you think, and Debian does make funding available for events. So, if you want to grow Debian in your area, feel free to join us at #debian-localgroups on the OFTC IRC network, also plumbed on Matrix at #debian-localgroups:matrix.debian.social where we ll try to answer any questions you might have and guide you through the process!
Oh and btw South Africa won the Rugby!
Dear Debian community,
this are my bits from DPL for August.
Happy Birthday Debian
On 16th of August Debian celebrated its 31th birthday. Since I'm
unable to write a better text than our great publicity team I'm
simply linking to their article for those who might have missed it:
https://bits.debian.org/2024/08/debian-turns-31.html
Removing more packages from unstable
Helmut Grohne argued for more aggressive package removal and
sought consensus on a way forward. He provided six examples of processes
where packages that are candidates for removal are consuming valuable
person-power. I d like to add that the Bug of the Day initiative (see
below) also frequently encounters long-unmaintained packages with popcon
votes sometimes as low as zero, and often fewer than ten.
Helmut's email included a list of packages that would meet the suggested
removal criteria. There was some discussion about whether a popcon vote
should be included in these criteria, with arguments both for and
against it. Although I support including popcon, I acknowledge that
Helmut has a valid point in suggesting it be left out.
While I ve read several emails in agreement, Scott Kitterman made
a valid point "I don't think we need more process. We just need
someone to do the work of finding the packages and filing the bugs." I
agree that this is crucial to ensure an automated process doesn t lead
to unwanted removals. However, I don t see "someone" stepping up to file
RM bugs against other maintainers' packages. As long as we have strict
ownership of packages, many people are hesitant to touch a package, even
for fixing it. Asking for its removal might be even less well-received.
Therefore, if an automated procedure were to create RM bugs based on
defined criteria, it could help reduce some of the social pressure.
In this aspect the opinion of Niels Thykier is interesting: "As
much as I want automation, I do not mind the prototype starting as a
semi-automatic process if that is what it takes to get started."
The urgency of the problem to remove packages was put by CharlesPlessy
into the words: "So as of today, it is much less work to
keep a package rotting than removing it." My observation when trying to
fix the Bug of the Day exactly fits this statement.
I would love for this discussion to lead to more aggressive removals
that we can agree upon, whether they are automated, semi-automated, or
managed by a person processing an automatically generated list
(supported by an objective procedure). To use an analogy: I ve found
that every image collection improves with aggressive pruning. Similarly,
I m convinced that Debian will improve if we remove packages that no
longer serve our users well.
DEP14 / DEP18
There are two DEPs that affect our workflow for maintaining
packages particularly for those who agree on using Git for Debian
packages. DEP-14 recommends a standardized layout for Git packaging
repositories, which benefits maintainers working across teams and makes
it easier for newcomers to learn a consistent repository structure.
DEP-14 stalled for various reasons. Sam Hartman suspected it might
be because 'it doesn't bring sufficient value.' However, the assumption
that git-buildpackage is incompatible with DEP-14 is incorrect, as
confirmed by its author, Guido G nther. As one of the two key tools
for Debian Git repositories (besides dgit) fully supports DEP-14, though
the migration from the previous default is somewhat complex.
Some investigation into mass-converting older formats to DEP-14 was
conducted by the Perl team, as Gregor Hermann pointed out..
The discussion about DEP-14 resurfaced with the suggestion of DEP-18.
Guido G nther proposed the title Encourage Continuous Integration and Merge
Request-Based Collaboration for Debian Packages ,
which more accurately reflects the DEP's technical intent.
Otto Kek l inen, who initiated DEP-18 (thank you, Otto), provided a good
summary of the current status. He also assembled a very helpful
overview of Git and GitLab usage in other Linux distros.
More Salsa CI
As a result of the DEP-18 discussion, Otto Kek l inen suggested
implementing Salsa CI for our top popcon packages.
I believe it would be a good idea to enable CI by default across Salsa
whenever a new repository is created.
Progress in Salsa migration
In my campaign, I stated that I aim to reduce the number of
packages maintained outside Salsa to below 2,000. As of March 28, 2024,
the count was 2,368. Today, it stands at 2,187 (UDD query: SELECT DISTINCT
count(*) FROM sources WHERE release = 'sid' and vcs_url not like '%salsa%' ;).
After a third of my DPL term (OMG), we've made significant progress,
reducing the amount in question (369 packages) by nearly half. I'm
pleased with the support from the DDs who moved their packages to Salsa.
Some packages were transferred as part of the Bug of the Day initiative
(see below).
Bug of the Day
As announced in my 'Bits from the DPL' talk at DebConf, I started
an initiative called Bug of the Day. The goal is to train newcomers
in bug triaging by enabling them to tackle small, self-contained QA
tasks. We have consistently identified target packages and resolved at
least one bug per day, often addressing multiple bugs in a single
package.
In several cases, we followed the Package Salvaging procedure outlined
in the Developers Reference. Most instances were either welcomed by
the maintainer or did not elicit a response. Unfortunately, there was
one exception where the recipient of the Package Salvage bug expressed
significant dissatisfaction. The takeaway is to balance formal
procedures with consideration for the recipient s perspective.
I'm pleased to confirm that the Matrix channel has seen an increase
in active contributors. This aligns with my hope that our efforts would
attract individuals interested in QA work. I m particularly pleased
that, within just one month, we have had help with both fixing bugs and
improving the code that aids in bug selection.
As I aim to introduce newcomers to various teams within Debian, I also
take the opportunity to learn about each team's specific policies
myself. I rely on team members' assistance to adapt to these policies. I
find that gaining this practical insight into team dynamics is an
effective way to understand the different teams within Debian as DPL.
Another finding from this initiative, which aligns with my goal as DPL,
is that many of the packages we addressed are already on Salsa but have
not been uploaded, meaning their VCS fields are not published. This
suggests that maintainers are generally open to managing their packages
on Salsa. For packages that were not yet on Salsa, the move was
generally welcomed.
Publicity team wants you
The publicity team has decided to resume regular meetings to coordinate
their efforts. Given my high regard for their work, I plan to attend
their meetings as frequently as possible, which I began doing with the
first IRC meeting.
During discussions with some team members, I learned that the team could
use additional help. If anyone interested in supporting Debian with
non-packaging tasks reads this, please consider introducing yourself to
debian-publicity@lists.debian.org. Note that this is a publicly archived
mailing list, so it's not the best place for sharing private
information.
Kind regards
Andreas.
Another short status update of what happened on my side last month.
Quite a bit of time went
into helping organize the FrOSCon FOSS on Mobile dev room (day 1, day 2, summary) but that was all worth it and fun - so was releasing Phosh 0.41.0 (which incidetally happened right before FrOScon). A three years old MR to xdg-spec to add call categories landed (thanks Matthias) allowing us to finally provide proper feedback for e.g. IM calls too. The rest was some OSK improvements (around Indic language support via varnam and layout configuration), some Cell Broadcast advancements (thanks to NGI0 for supporting this) but also some fixes. Here's the details:
Phosh
Debug crash when swiping away keyboard on lockscreen (MR).
Fix outdated clock when swiping back from lockscreen plugins (MR)
Allow to select OSK layouts (MR). This ensures only actually available layouts can be selected. Currently used by phosh-osk-stub but can easily be extended to squeekboard once it provides the information.
Rework most bits of Cell Broadcast to move it closer to undraft status (MR).
(Remaining bits affect enabling of unsolicited messages and setting channels).
Help Development
If you want to support my work see donations. This includes
a list of hardware we want to improve support for. Thanks a lot to all current and past donors.
Since my last blog post about the PineTime [1] I haven t done anything exciting with it. I ve been wearing it every day and it s working reasonably well for me. It s been working better since I changed to a Samsung Galaxy Note 9 as my main phone [2], so it seems that the Huawei Mate 10 Pro has some issues with Bluetooth that were making it unreliable.
A relative also has one which is working well for them but which had some problems, I only discovered that holding the button down for a long time (longer than usual for device reset) makes a PineTime reboot because of their issues. I also once had their device get into a bad state where the only thing I could do was flash a newer firmware which fortunately fixed the problem.
My latest issue is the battery life. Recently it has been taking ages to get above about 90% charge when charging and the time taken to go down to ~70% when I charge it seems to be decreasing. Yesterday it suddenly went to 13% after being 73% the previous night. Then it stayed at 13% all day. It seems quite inaccurate. But also it doesn t seem to be lasting as long as before.
Generally it seems to me that Pine64 products are almost great. I won t rule out the possibility of a newer firmware for the PineTime alleviating the battery issues (or at least reporting the status accurately) and making Bluetooth connectivity more reliable (even on older phones). For the PinePhonePro an update to Mobian could reduce power wasting from user space (there s an issue that I have reported in Plasma Mobile but no-one is interested on working on this before KDE 6), and a kernel update could improve things. But I don t think there s a possibility of it ever having the battery last a day while polling Matrix and Jabber servers which is something that every Android phone can do without problems.
I m finishing typing up this blog entry hours before my last 13 hour leg back home, after I spent 2 weeks in Busan, South Korea for DebCamp24 and DebCamp24. I had a rough year and decided to take it easy this DebConf. So this is the first DebConf in a long time where I didn t give any talks. I mostly caught up on a bit of packaging, worked on DebConf video stuff, attended a few BoFs and talked to people. Overall it was a very good DebConf, which also turned out to be more productive than I expeced it would.
In the welcome session on the first day of DebConf, Nicolas Dandrimont mentioned that a benefit of DebConf is that it provides a sort of caffeine for your Debian motivation. I could certainly feel that affect swell as the days went past, and it s nice to be excited about some ideas again that would otherwise be fading.
Recovering DPL
It s a bit of a gear shift being DPL for 4 years, and DebConf Committee for nearly 5 years before that, and then being at DebConf while some issue arise (as it always does during a conference). At first I jump into high alert mode, but then I have to remind myself it s not your problem anymore and let others deal with it.
It was nice spending a little in-person time with Andreas Tille, our new DPL, we did some more handover and discussed some current issues. I still have a few dozen emails in my DPL inbox that I need to collate and forward to Andreas, I hope to finish all that up by the end of August.
During the Bits from the DPL talk, the usual question came up whether Andreas will consider running for DPL again, to which he just responded in a slide Maybe . I think it s a good idea for a DPL to do at least two terms if it all works out for everyone, since it takes a while to get up to speed on everything.
Also, having been DPL for four years, I have a lot to say about it, and I think there s a lot we can fix in the role, or at least discuss it. If I had the bandwidth for it I would have scheduled a BoF for it, but I ll very likely do that for the next DebConf instead!
Video team
I set up the standby loop for the video streaming setup. We call it loopy, it s a bunch of OBS scenes that provide announcements, shows sponsors, the schedule and some social content. I wrote about it back in 2020, but it s evolved quite a bit since then, so I m probably due to write another blog post with a bunch of updates on it. I hope to organise a video team sprint in Cape Town in the first half of next year, so I ll summarize everything before then.
It would ve been great if we could have some displays in social areas that could show talks, the loop and other content, but we were just too pressed for time for that. This year s DebConf had a very compressed timeline, and there was just too much that had to be done and that had to be figured out on the last minute. This put quite a lot of strain on the organisers, but I was glad to see how, for the most part, most attendees were very sympathetic to some rough edges (but I digress ).
I added more of the OBS machine setup to the videoteam s ansible repository, so as of now it just needs an ansible setup and the OBS data and it s good to go. The loopy data is already in the videoteam git repository, so I could probably just add a git pull and create some symlinks in ansible and then that machine can be installed from 0% to 100% by just installing via debian-installer with our ansible hooks.
This DebConf I volunteered quite a bit for actual video roles during the conference, something I didn t have much time for in recent DebConfs, and it s been fun, especially in a session or two where nearly none of the other volunteers showed up. Sometimes chaos is just fun :-)
Baekyongee is the university mascot, who s visible throughout the university. So of course we included this four legged whale creature on the loop too!
Packaging
I was hoping to do more packaging during DebCamp, but at least it was a non-zero amount:
Uploaded gdisk 1.0.10-2 to unstable (previously tested effects of adding dh-sequence-movetousr) (Closes: #1073679).
Worked a bit on bcachefs-tools (updating git to 1.9.4), but has a build failure that I need to look into (we might need a newer bindgen) update: I m probably going to ROM this package soon, it doesn t seem suitable for packaging in Debian.
Calamares: Tested a fix for encrypted installs, and uploaded it.
Calamares: Uploaded (3.3.8-1) to backports (at the time of writing it s still in backports-NEW).
Pixelorama 1.0 I did some initial packaging for Pixelorama back when we did the MiniDebConf Gaming Edition, but it had a few stoppers back then. Version 1.0 seems to fix all of that, but it depends on Godot 4.2 and we re still on the 3 series in Debian, so I ll upload this once Godot 4.2 hits at least experimental. Godot software/games is otherwise quite easy to run, it s basically just source code / data that is installed and then run via godot-runner (godot3-runner package in Debian).
BoFs
Python Team BoF
Link to the etherpad / pad archive link and video can be found on the talk page: https://debconf24.debconf.org/talks/31-python-bof/
The session ended up being extended to a second part, since all the issues didn t fit into the first session.
I was distracted by too many thing during the Python 3.12 transition (to the point where I thought that 3.11 was still new in Debian), so it was very useful listening to the retrospective of that transition.
There was a discussion whether Python 3.13 could still make it to testing in time for freeze, and it seems that there is consensus that it can, although, likely with new experimental features like disabling the global interpreter lock and the just in time compiler disabled.
I learned for the first time about the dead batteries project, PEP-0594, which removes ancient modules that have mostly been superseded, from the Python standard library.
There was some talk about the process for changing team policy, and a policy discussion on whether we should require autopkgtests as a SHOULD or a MUST for migration to testing. As with many things, the devil is in the details and in my opinion you could go either way and achieve a similar result (the original MUST proposal allowed exceptions which imho made it the same as the SHOULD proposal).
There s an idea to do some ongoing remote sprints, like having co-ordinated days for bug squashing / working on stuff together. This is a nice idea and probably a good way to energise the team and also to gain some interest from potential newcomers.
Louis-Philipe V ronneau was added as a new team admin and there was some discussion on various Sphinx issues and which Lintian tags might be needed for Python 3.13. If you want to know more, you probably have to watch the videos / read the notes :)
Debian.net BoF
Link to the etherpad / pad archive link can be found on the talk page: https://debconf24.debconf.org/talks/37-debiannet-team-bof
Debian Developers can set up services on subdomains on debian.net, but a big problem we ve had before was that developers were on their own for hosting those services. This meant that they either hosted it on their DSL/fiber connection at home, paid for the hosting themselves, or hosted it at different services which became an accounting nightmare to claim back the used funds. So, a few of us started the debian.net hosting project (sometimes we just call it debian.net, this is probably a bit of a bug) so that Debian has accounts with cloud providers, and as admins we can create instances there that gets billed directly to Debian.
We had an initial rush of services, but requests have slowed down since (not really a bad thing, we don t want lots of spurious requests). Last year we did a census, to check which of the instances were still used, whether they received system updates and to ask whether they are performing backups. It went well and some issues were found along the way, so we ll be doing that again.
We also gained two potential volunteers to help run things, which is great.
Debian Social BoF
Link to the etherpad / pad archive link can be found on the talk page: https://debconf24.debconf.org/talks/34-debiansocial-bof
We discussed the services we run, you can view the current state of things at: https://wiki.debian.org/Teams/DebianSocial
Pleroma has shown some cracks over the last year or so, and there are some forks that seem promising. At the same time, it might be worth while considering Mastodon too. So we ll do some comparison of features and maintenance and find a way forward. At the time when Pleroma was installed, it was way ahead in terms of moderation features.
Pixelfed is doing well and chugging along nicely, we should probably promote it more.
Peertube is working well, although we learned that we still don t have all the recent DebConf videos on there. A bunch of other issues should be fixed once we move it to a new machine that we plan to set up.
We re removing writefreely and plume. Nice concepts, but it didn t get much traction yet, and no one who signed up for these actually used it, which is fine, some experimentation with services is good and sometimes they prove to be very popular and other times not.
The WordPress multisite instance has some mild use, otherwise haven t had any issues.
Matrix ended up to be much, much bigger than we thought, both in usage and in its requirements. It s very stateful and remembers discussions for as long as you let it, so it s Postgres database is continuously expanding, this will also be a lot easier to manage once we have this on the new host.
Jitsi is also quite popular, but it could probably be on jitsi.debian.net instead (we created this on debian.social during the initial height of COVID-19 where we didn t have the debian.net hosting yet), although in practice it doesn t really matter where it lives.
Most of our current challenges will be solved by moving everything to a new big machine that has a few public IPs available for some VMs, so we ll be doing that shortly.
Debian Foundation Discussion BoF
This was some brainstorming about the future structure of Debian, and what steps might be needed to get there. It s way too big a problem to take on in a BoF, but we made some progress in figuring out some smaller pieces of the larger puzzle. The DPL is going to get in touch with some legal advisors and our trusted organisations so that we can aim to formalise our relationships a bit more by the time it s DebConf again.
I also introduced my intention to join the Debian Partners delegation. When I was DPL, I enjoyed talking with external organisations who wanted to help Debian, but helping external organisations help Debian turned out to be too much additional load on the usual DPL roles, so I m pursuing this with the Debian Partners team, more on that some other time.
This session wasn t recorded, but if you feel like you missed something, don t worry, all intentions will be communicated and discussed with project members before anything moves forward. There was a strong agreement in the room though that we should push forward on this, and not reach another DebConf where we didn t make progress on formalising Debian s structure more.
Social
Conference Dinner
Conference Dinner Photo from Santiago
The conference dinner took place in the university gymnasium. I hope not many people do sports there in the summer, because it got HOT. There was also some interesting observations on the thermodynamics of the attempted cooling solutions, which was amusing. On the plus side, the food was great, the company was good, and the speeches were kept to a minimum, so it was a great conference dinner, even though it was probably cut a bit short due to the heat.
Cheese and Wine
Cheese and Wine happened on 1 August, which happens to be the date I became a DD at DebConf17 in Montr al seven years before, so this was a nice accidental celebration of my Debiversary :)
Since I m running out of time, I ll add some more photos to this post some time after publishing it :P
Group Photo
As per DebConf tradition, Aigars took the group photo. You can find the high resolution version on Debian s GitLab instance.
Debian annual conference Debconf 24, Busan, South Korea Photography: Aigars Mahinovs aigarius@debian.org License: CC-BYv3+ or GPLv2+
Talking
Ah yes, talking to people is a big part of DebConf, but I didn t keep track of it very well.
I mostly listened to Alper a bit about his ideas for his talk about debian installer.
I talked to Rhonda a bit about ActivityPub and MQTT and whether they could be useful for publicising Debian activity.
Listened to Gunnar and Julian have a discussion about GPG and APT which was interesting.
We had the usual continuous keysigning party. Besides it s intended function, this is always a good ice breaker and a way to for shy people to meet other shy people.
and many other fly-by discussions.
Stuff that didn t happen this DebConf
loo.py A simple Python script that could eventually replace the obs-advanced-scene-switcher sequencer in OBS. It would also be extremely useful if we d ever replace OBS for loopy. I was hoping to have some time to hack on this, and try to recreate the current loopy in loo.py, but didn t have the time.
toetally This year videoteam had to scramble to get a bunch of resistors to assemble some tally light. Even when assembled, they were a bit troublesome. It would ve been nice to hack on toetally and get something ready for testing, but it mostly relies on having something like a rasbperry pi zero with an attached screen in order to work on further. I ll try to have something ready for the next mini conf though.
extrepo on debian live I think we should have extrepo installed by default on desktop systems, I meant to start a discussion on this, but perhaps it s just time I go ahead and do it and announce it.
Live stream to peertube server It would ve been nice to live stream DebConf to PeerTube, but the dependency tree to get this going got a bit too huge. Following our plans discussed in the Debian Social BoF, we should have this safely ready before the next MiniDebConf and should be able to test it there.
Desktop Egg there was this idea to get a stand-in theme for Debian testing/unstable until the artwork for the next release is finalized (Debian bug: #1038660), I have an idea that I meant to implement months ago, but too many things got in the way. It s based on Juliette Taka s Homeworld theme, and basically transforms the homeworld into an egg. Get it? Something that hasn t hatched yet? I also only recently noticed that we never used the actualhomeworld graphics (featuring the world image) in the final bullseye release. lol.
So, another DebConf and another new plush animal. Last but not least, thanks to PKNU for being such a generous and fantastic host to us! See you again at DebConf25 in Brest, France next year!
Dear Debian community,
this are my bits from DPL written at my last day at another great
DebConf.
DebConf attendance
At the beginning of July, there was some discussion with the bursary and
content team about sponsoring attendees. The discussion continued at
DebConf.
I do not have much experience with these discussions. My summary is that
while there is an honest attempt to be fair to everyone, it did not seem to
work for all, and some critical points for future discussion remained. In
any case, I'm thankful to the bursary team for doing such a time-draining
and tedious job.
Popular packages not yet on Salsa at all
Otto Kek l inen did some interesting investigation about
Popular packages not yet on Salsa at all.
I think I might provide some more up to date list soon by some UDD query
which considers more recent uploads than the trends data soon. For
instance wget was meanwhile moved to Salsa (thanks to No l K the for this).
Keep on contacting more teams
I kept on contacting teams in July. Despite I managed to contact way
less teams than I was hoping I was able to present some conclusions in
the Debian Teams exchange BoF and Slide 16/23 of my
Bits from the DPL talk.
I intend to do further contacts next months.
Nominating Jeremy B cha for GNOME Advisory Board
I've nominated Jeremy B cha to
GNOME Advisory Board.
Jeremy has volunteered to represent Debian at
GUADEC in Denver.
DebCamp / DebConf
I attended DebCamp starting from 22 July evening and had a lot of fun with
other attendees. As always DebConf is some important event nearly
every year for me. I enjoyed Korean food, Korean bath, nature at the
costline and other things.
I had a small event without video coverage
Creating web galleries including maps from a geo-tagged photo collection.
At least two attendees of this workshop confirmed success in creating their
own web galleries.
I used DebCamp and DebConf for several discussions. My main focus was on
discussions with FTP master team members Luke Faraone, Sean Whitton, and
Utkarsh Gupta. I'm really happy that the four of us absolutely agree on
some proposed changes to the structure of the FTP master team, as well
as changes that might be fruitful for the work of the FTP master team
itself and for Debian developers regarding the processing of new
packages.
My explicit thanks go to Luke Faraone, who gave a great introduction to
FTP master work in their
BoF.
It was very instructive for the attending developers to understand how the
FTP master team checks licenses and copyright and what workflow is used
for accepting new packages.
In the first days of DebConf, I talked to representatives of DebConf
platinum sponsor WindRiver, who announced the derivative
eLxr. I warmly welcome
this new derivative and look forward to some great cooperation. I also
talked to the representative of our gold sponsor, Microsoft.
My first own event was the
Debian Med BoF.
I'd like to repeat that it might not only be interesting for people
working in medicine and microbiology but always contains some hints how
to work together in a team.
As said above I was trying to summarise some first results of my team
contacts and got some further input from other teams in the
Debian Teams exchange BoF.
Finally, I had my
Bits from DPL talk.
I received positive responses from attendees as well as from remote
participants, which makes me quite happy. For those who were not able to
join the events on-site or remotely, the videos of all events will be
available on the DebConf site soon. I'd like to repeat the explicit need
for some volunteers to join the Lintian team. I'd also like to point out
the "Tiny tasks" initiative I'd like to start (see below).
BTW, if someone might happen to solve my quiz for the background images
there is a
summary page
in my slides which might help to assign every slide to some DebConf. I
could assume that if you pool your knowledge you can solve more than just
the simple ones. Just let me know if you have some solution. You can add
numbers to the rows and letters to the columns and send me:
2000/2001: Uv + Wx 2002: not attended 2003: Yz 2004: not attended 2005: 2006: not attended 2007: ... 2024: A1
This list provides some additional information for DebConfs I did not
attend and when no video stream was available. It also reminds you about
the one I uncovered this year and that I used two images from 2001 since
I did not have one from 2000. Have fun reassembling good memories.
Tiny tasks: Bug of the day
As I mentioned in my
Bits from DPL talk,
I'd like to start a "Tiny tasks" effort within Debian. The first type of
tasks will be the
Bug of the day
initiative. For those who would like to join, please join the corresponding
Matrix channel. I'm
curious to see how this might work out and am eager to gain some initial
experiences with newcomers. I won't be available until next Monday, as I'll
start traveling soon and have a family event (which is why I need to leave
DebConf today after the formal dinner).
Kind regards from DebConf in Busan
Andreas.
A short status update on what happened on my side last month. Looking
at unified push support for Chatty prompted some libcmatrix fixes and
Chatty improvements (benefiting other protocols like SMS/MMS as well).
The Bluetooth status page in Phosh was a slightly larger change code
wise as we also enhanced our common widgets for building status pages,
simplifying the Wi-Fi status page and making future status pages
simpler. But as usual investigating bugs, reviewing patches (thanks!)
and keeping up with the changing world around us is what ate most of
the time.
Phosh
A Wayland Shell for mobile devices
I've tried Android Element app for matrix first time during Debconf. It feels good. For me it's a better IRC.
I've been using it on my Chromebook and one annoyance is that I haven't found a keyboard shortcut for sending messages.
I would have expected shift or ctrl with Enter would send the current message, but so far I have been touching the display to send messages.
Can I fix this? Where is the code?
Here comes the 3rd article of the 5-episode blog post series on Polis, written by Guido Berh rster, member of staff at my company Fre(i)e Software GmbH.Enjoy also this read on Guido's work on Polis,
Mike
Table of Contents of the Blog Post Series
Issues extending Polis and adjusting our goals (this article)
Creating (a) new frontend(s) for Polis
Current status and roadmap
Polis - Issues extending Polis and adjusting our Goals
After the initial implementation of limited branding support, user
feedback and the involvement of an UX designer lead to the conclusion that we
needed more far-reaching changes to the user interface in order to reduce
visual clutter, rearrange and improve UI elements, and provide better
integration with the websites in which conversations are embedded.
Challenges when visualizing Data in Polis
Polis visualizes groups using a spatial projection of users based on
similarities in voting behavior and places them in two to five groups
using a clustering algorithm.
During our testing and evaluation users were rarely able to interpret the
visualization and often intuitively made incorrect assumptions e.g. by
associating the filled area of a group with its significance or size. After
consultation with a member of the Multi-Agent Systems (MAS) Group at the
University of Groningen we chose to temporarily replace the visualization
offered by Polis with simple bar charts representing agreement or disagreement
with statements of a group or the majority. We intend to revisit this and
explore different forms of visualization at a later point in time.
The different factors playing into the weight attached to statements which
determine the pseuodo-random order in which they are presented for voting
( comment routing ) proved difficult to explain to stakeholders and users and
the admission of the ad-hoc and heuristic nature of the used algorithm1 by
Polis authors lead to the decision to temporarily remove this feature.
Instead, statements should be placed into three groups, namely
metadata questions,
seed statements,
and participant statements
Statements should then be sorted by group but in a fully randomized order
within the group so that metadata questions would be presented before seed
statements which would be presented before participant s statements. This
simpler method was deemed sufficient for the scale of our pilot projects,
however we intend to revisit this decision and explore different methods of
comment routing in cooperation with our scientific partners at a later point
in time.
An evaluation of the requirements for implementing mandatory authentication and
adding support for additional authentication methods to Polis showed that
significant changes to both the administration and participation frontend were
needed due to a lack of an abstraction layer or extension mechanism and the
current authentication providers being hardcoded in many parts of the code
base.
A New Frontend is born: Particiapp
Based on the implementation details of the participation frontend, the invasive
nature of the changes required, and the overhead of keeping up with active
upstream development it became clear that a different, more flexible approach
to development was needed. This ultimately lead to the creation of
Particiapp, a new Open Source project providing the building blocks and
necessary abstraction layers for rapid protoyping and experimentation with
different fontends which are compatible with but independent from Polis.
Small, Christopher T., Bjorkegren, Michael, Erkkil , Timo, Shaw, Lynette and Megill, Colin (2021). Polis: Scaling deliberation by mapping high dimensional opinion spaces. Recerca. Revista de Pensament i An lisi, 26(2), pp. 1-26.
Armadillo is a powerful
and expressive C++ template library for linear algebra and scientific
computing. It aims towards a good balance between speed and ease of use,
has a syntax deliberately close to Matlab, and is useful for algorithm
development directly in C++, or quick conversion of research code into
production environments. RcppArmadillo
integrates this library with the R environment and language and is
widely used by (currently) 1158 other packages on CRAN, downloaded 35.1 million
times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint
/ vignette) by Conrad and myself has been cited 587 times according
to Google Scholar.
Conrad released a new
major upstream version 14.0.0 a couple of days ago. We had been testing
this new version extensively over several rounds of reverse-dependency
checks across all 1100+ packages. This revealed nine packages requiring
truly minor adjustments which eight maintainers made in a matter of
days; all this was coordinated in issue
#443. Following the upload, CRAN noticed one more issue (see
issue
#446) but this turned out to be local to the package. There are also
renewed deprecation warnings with some Armadillo changes which we will
need to address one-by-one. Last but not least with this release we also
changed the package versioning scheme to follow upstream Armadillo more closely.
The set of changes since the last CRAN release follows.
Changes in
RcppArmadillo version 14.0.0-1 (2024-07-05)
Upgraded to Armadillo release 14.0.0 (Stochastic Parrot)
C++14 is now the minimum recommended C++ standard
Faster handling of compound expressions by
as_scalar(), accu(),
dot()
Faster interactions between sparse and dense matrices
Expanded stddev() to handle sparse matrices
Expanded relational operators to handle expressions between
sparse matrices and scalars
Added .as_dense() to obtain dense vector/matrix
representation of any sparse matrix expression
Updated physical constants to NIST 2022 CODATA values
New package version numbering scheme following upstream
versions
Re-enabling ARMA_IGNORE_DEPRECATED_MARKE for silent
CRAN builds
(in case you haven't noticed, apt now has the --update option for the
upgrade and install commands, although not available on stable yet)
Availability
Debian unstable - Since 2024-07-02
Debian testing - Since 2024-07-18
Debian 12/bookworm backports - Expected by the end of August 2024.
Debian 12/bookworm - Due to the mechanisms we have in place to make sure
Debian stable is in fact stable, we will never be able to ship this in the
regular repository. Users can make use of the
backports repositories instead.
Debian derivatives - Rolling releases will get it by the time it's on Debian
testing (e.g.: Kali Linux). Stable derivatives only in their next major release.
The challenge
HTTP3 is fresh new, well... not really, but at least fresh enough that I'm not
aware of any other Linux distribution supporting it on curl, the reason is
likely two-fold:
OpenSSL is not there yet
OpenSSL still doesn't have proper HTTP3 support, and given that OpenSSL is so
widely used, almost every curl distributor/packager will build curl with it
and thus changing the TLS backend to something else is risky.
Unfortunately, proper support for the OpenSSL libcurl is unlikely to come anytime
before the end of this year, the OpenSSL performance is not good enough
yet as of version 3.3.
Daniel Stenberg has written about the state of this multiple times, most
recently at HTTP/3 in curl mid
2024, if
you're interested, I suggest reading through his other posts as well.
Some might have noticed that nginx does support HTTP3 through OpenSSL,
although when you look closely, it's not exactly perfect:
An SSL library that provides QUIC support is recommended to build nginx, such as BoringSSL, LibreSSL, or QuicTLS. Otherwise, the OpenSSL compatibility layer will be used that does not support early data.
As you can see, they don't recommend using OpenSSL, and when doing so, you don't get complete support.
HTTP3 support for GnuTLS/nghttp3/ngtcp2 is recent
The non-experimental support arrived back in October
2023,
and so that's when I started seriously planning for this.
curl has been working on HTTP3 support for years, and so it did support other
TLS backends before that, but out of them, the one most feasible for a
distribution to ship would be GnuTLS, which gets HTTP3 support through ngctp2 and
nghttp3.
How it was done
The Debian curl package has historically shipped at least two variants of libcurl, an
OpenSSL and a GnuTLS one.
The OpenSSL libcurl can't support HTTP3 for the reasons explained above, but
the GnuTLS libcurl can (with ngtcp2 and nghtp3).
Debian packages can choose which version of libcurl to link against (without
having to modify any upstream source code). Debian's "git" package being a famous
example of a package that links against the GnuTLS libcurl.
Enabling HTTP3 on curl was done in three steps:
Make sure all required dependencies fulfill the minimum requirements.
Enable HTTP3 for GnuTLS libcurl.
Change the libcurl used by the curl CLI, from OpenSSL to GnuTLS.
curl's HTTP3 support requires a somewhat recent version of nghttp3 and
updating that required a transition (due to the SONAME bump), while we've also
had months of freeze for transitions due to the time_t
transition.
After the dependencies were in place, enabling HTTP3 for the GnuTLS libcurl was
straightforward.
Then, for the last part, we had to switch the TLS backend used by the curl CLI.
Doing the swap is also quite
easy
on the packaging level, but we have to consider the chances of this change
breaking our users' environments.
Ensuring there are no breakages
The first thing to consider regarding breakages is that this change is not
going to be pushed directly to the current Debian stable releases, it will be
present in the next stable release (13/trixie) but the current one will stick to the
version that's already shipped.
Secondly, we have to consider the risk of losing the ability to use certain
parameters from the curl CLI which could be limited to the OpenSSL backend.
During curl-up 2024, the curl developers pointed out the existence of a page
that lists the TLS related options and the backends they work
with.
Analysing that page, ignoring all of the options that are suffixed with "BLOB"
(only pertinent to the library, not the CLI), the only one left which is
attention worthy is CURLOPT_ECH.
This experimental feature requires a special build of OpenSSL, as ECH is not
yet supported in OpenSSL releases. In contrast ECH is supported by the latest
BoringSSL and wolfSSL releases.
As it turns out, Encrypted Client Hello is experimental and it's not
supported by the vanilla OpenSSL.
This was enough of an investigation for me to go ahead with the change. Noting
that even in the worst case scenario (we find a horrible regression), we can
rollback without having affected a single stable release.
Now that the package is on Debian unstable, the CI tests (autopkgtest) of every
package that depends on curl is currently running, the results are compared
against the migration-reference (in this case, the curl CLI with OpenSSL,
before the change).
If everything goes right, curl with HTTP3 support will migrate to Debian
testing in around 5 days. If we spot any issues, we'll have to solve them
first and it's going to be hard to predict how long it takes, although it's
fair to expect less than a month.
Acknowledgements
It took us a bit longer than expected to be able to enable HTTP3, nonetheless it's
still early enough to be excited about.
A lot of people were crucial to make this happen.
I should recognize in the first place, obviously, the curl developers and the
developers of the supporting libraries: GnuTLS, nghttp3, ngtcp2. Participating
in the curl-up
2024
conference helped me get motivated to push this through, besides becoming aware
of the right documentation to research for impact.
On the Debian side, Sakirnth Nagarasa <sakirnth> was responsible for updating
and taking care of the transition for nghttp3 and ngtcp2.
Also on the Debian side, I've got loads of help and support from the
co-maintainers of the curl package: Sergio Durigan Junior <sergiodj> and Carlos
Henrique Lima Melara <charles>.
Changes since publication
2024-07-18
Update date of availability for Debian testing and expected date for bookworm backports.
We have historically spoken Portuguese in the room but we'll switch to English in case anyone joins.
Availability (comes installed with the curl package):
Debian unstable - Since 2024-07-02
Debian testing - Since 2024-07-18
Debian 12/bookworm backports - Expected by the end of August 2024.
Debian 12/bookworm - Depends on whether Debian's release team will approve
it, it could be available in the next point release.
Debian derivatives - Rolling releases will get it by the time it's on Debian
testing (e.g.: Kali Linux). Stable derivatives only in their next major release.
Smoother CLI experience
Starting with curl version 8.8.0-2, the Debian's curl package now ships a wcurl
executable.
wcurl is the solution for those who just need to download files without having
to remember curl's parameters for things like automatically naming the files.
Some people, myself included, would fall back to using wget whenever there was a
need to download a file. Sometimes even installing wget just for that usecase.
After all, it's easier to remember "apt install wget" rather than "curl -L -O -C - ...".
wcurl consists of a simple shell script that provides sane defaults for the curl
invocation, for when the use case is to just download files.
By default, wcurl will:
Encode whitespaces in URLs;
Download multiple URLs in parallel if the installed curl's version is >= 7.66.0;
Follow redirects;
Automatically choose a filename as output;
Avoid overwriting files if the installed curl's version is >= 7.83.0 (--no-clobber);
Perform retries;
Set the downloaded file timestamp to the value provided by the server, if available;
Default to the protocol used as https if the URL doesn't contain any;
Disable curl's URL globbing parser so and [] characters in URLs are not treated specially.
Example to download a single file:
wcurl example.com/filename.txt
If you ever need to set a custom flag, you can make use of the --curl-options
wcurl option, anything set there will be passed to the curl invocation.
Just beware that if you need to set any custom flags, it's likely you will be
better served by calling curl directly. The --curl-options option is there to
allow for some flexibility in unforeseen circumstances.
The need for wcurl
I've always felt a bit ashamed of not remembering curl's parameters for
downloading a file and automatically naming it, having resorted to wget most of
the times this was needed (even installing wget when it wasn't there, just for
this). I've spoken to a few other experienced people I know and confirmed what
could be obvious to others: a lot of people struggle with this.
Recently, the curl project released the results of 2024's curl
survey, which
also showed this is as a much needed feature, just look at some of the answers:
Q: Which curl command line option do you think needs improvement and how?
-O, I really want wget like functionality where I don't have to specify the name
Downloading a file (like wget) could be improved - with automatic naming of the file
downloading files - wget is much cleaner
I wish the default behaviour when GETting a binary was to drop it on disk. That's the only
reason 'wget foo.tgz" is still ingrained in my muscle memory .
Maybe have a way to download without specifying something in -o (the only reason i used wget
still)
--remote-time should be default
--remote-name-all could really use a short flag
Q: If you miss support for something, tell us what!
"Write the data to the file named in the URL (or in redirects if I'm feeling daring), and
timestamp the file to the last-modified-date". This is the main reason I'm still using wget.
I can finally feel less bad about falling back to wget due to not remembering the
parameters I want.
Idealization vs. reality
I don't believe curl will ever change its default behavior in such a way that
would accommodate this need, as that would have a side-effect of breaking things
which expect the current behavior (the blast radius is literally the
solar system).
This means a new executable needs to be shipped side-by-side with curl, an
opportunity to start fresh and work with a more focused use case (to download
files).
Ideally, this new executable would be maintained by the curl project, make use
of libcurl under-the-hood, and be available everywhere. Nobody wants to worry
if their systems have the tool or not, it should always be there.
Given I'm just a Debian Developer, with not as much free time as I wish, I've
decided to write a simple shell script wrapper calling the curl CLI
under-the-hood.
wcurl will come installed with the curl package from now on, and I will check
with the release team about shipping it on the current Debian stable as well.
Shipping wcurl in other distros will be up to them (Debian-derivatives should
pick it up automatically, though).
We've tried to make it easy for anyone to ship this by using the curl license,
keeping the script POSIX-compliant, and shipping a manpage.
Maybe if there's enough interest across distributions, someone might sign up
for implementing this in upstream curl and increase its reach. I would be happy
with the curl project reusing the wcurl name when that happens. It's unlikely
that wcurl would be shipped by curl upstream as it is, assuming they would
prefer a solution that uses libcurl direclty (more similar to curl the CLI, to
maintain).
In the worst case, wcurl becomes a Debian-specific tool that only a few people
are aware of, in the best case, it becomes the new go-to CLI tool for simply
downloading files. I would be happy if at least someone other than me finds
it useful.
Naming is hard
When I started working on it, I was calling the new executable "curld"
(stands for "curl download"), but then when discussing this in one of our
weekly calls in the Debian Bras lia community, it was mentioned that this could
be confused for a daemon.
We then settled for the name "wcurl", suggested by Carlos Henrique Lima
Melara <charles>. It doesn't really stand for anything,
but it's very easy to remember.
You know... "it's that wget alternative for when you want to use curl instead"
:)
Acknowledgments
The idea for wcurl came a few days before the curl-up conference
2024.
I've been thinking a lot about developer productivity in the terminal lately,
different tools and better defaults. Before curl-up, I was also thinking about
packaging improvements for the curl package. I don't remember what exactly
happened, but I likely had to download something and felt a bit ashamed of
maintaining curl and not remembering the parameters to download files the way I
wanted.
I first discussed this idea in the conference, where I asked the
participants about it and there were no concerns raised, and some people said I should give it a go.
Participating in curl-up was a really great experience and I'm thankful for the
interactions I've had there.
On the Debian side, I've got reviews of the code and manpage by Sergio Durigan
Junior <sergiodj>, Guilherme Puida Moreira <puida> and Carlos Henrique Lima
Melara <charles>. Sergio ended up rewriting the tool to be POSIX-compliant (my
version was written in bash), so he takes all the credit for the portability.
Changes since publication
2024-07-18
Update date of availability for Debian testing and expected date for bookworm backports.
Mention charles as the person who suggested "wcurl" as a name.
Update wcurl's -o/--opts options, it's now just --curl-options.
Remove mention of language spoken in the Matrix room, we are using English now.
Introduction
In Australia the 3G mobile frequencies are to be reused so they are in the process of shutting down the 3G service. That means that everyone has to use VoLTE (Voice Over LTE) for phone calls (including emergency calls). The shutdown time varies by telco, Kogan Mobile (one of the better services which has good value for money and generally works well) shut down their 3G service in January. Aldi Mobile (another one of the good services which is slightly more expensive but has included free calls to most first-world countries and uses the largest phone network) will shut theirs down at the end of August.
For background there s a Fosdem talk about OpenSIPS with VoLTE and VoNR [1], it s more complex than you want to know. Also VoNR (Voice over New Radio) is the standard for 5G voice and it s different from VoLTE and has a fallback to VoLTE. Another good lecture for background information is the Fosdem talk on VoLTE at the handset end [2].
The PinePhonePro
In October 2023 I tried using my PinePhonePro as my main phone but that only lasted a few days due to problems with calls and poor battery life [3]. Since then I went back to the Huawei Mate 10 Pro that I bought refurbished in June 2019 for $389. So that has been my main phone for 5 years now, giving a cost of $1.50 per week. I had tried using a Huawei Nova 7i running Android without Google Play as an experiment but that had failed, I do many things that need Android apps [4].
I followed the PinePhone wiki to get my PinePhonePro working with VoLTE [5]. That worked fine for me, the only difference from the instructions is that I had to use device /dev/ttyUSB3 and that the modem kept resetting itself during the process and when that happened I had to kill minicom and start again. After changing the setting and saving it the PinePhonePro seemed to work well with VoLTE on a Kogan Mobile SIM (so definitely not using 3G).
One issue I have found is that Plasma Mobile (my preferred FOSS phone GUI) appears to have a library issue that results in polling every 14ms even when the screen is locked [6]. If you have a few processes doing that (which means the most lightly used Plasma system) it really hurts battery use. The maintainer has quite reasonably deferred action on this bug report given the KDE 6 transition. Later on in the Trixie development cycle I hope to get this issue resolved, I don t expect it to suddenly make battery life good. But it might make battery life acceptable.
I am now idly considering carrying around my PinePhonePro in a powered off state for situations where I might need to do high security operations (root logins to servers or online banking) but for which carrying a laptop isn t convenient. It will do well for the turn on, do 30 mins of work that needs security, and then turn off scenario.
Huawei Mate 10 Pro and Redmi 9A
The Huawei Mate 10 Pro has been my main phone for 5 years and it has worked well, so it would be ideal if it could do VoLTE as the PinePhonePro isn t ready yet.
All the web pages I ve seen about the Mate 10 Pro say that it will either allow upgrading to a VoLTE configuration if run with the right SIM or only support it with the right SIM. I did a test with a Chinese SIM which gave an option of turning on VoLTE but didn t allow any firmware updates and the VoLTE option went away when I put an Australian SIM in. Some forum comments had led me to believe that it would either permanently enable VoLTE or allow upgrading the firmware to one that enables VoLTE if I used a Chinese SIM but that is not the case. I didn t expect a high probability of success but I had to give it a go as it s a nice phone.
I did some tests on a Redmi 9A (a terrible phone that has really bad latency on the UI in spite of having reasonably good hardware). The one I tested on didn t have VoLTE enabled when I got it, to test that I used the code *#*#4636#*#* in the dialler to get the menu of SIM information and it showed that VoLTE was not provisioned. I then had to update to the latest release of Android for that phone and enter *#*#86583#*#* in the dialler to enable VoLTE, the message displayed after entering that magic number must end in DISABLE . I get the impression that the code in question makes the phone not check certain aspects of whether the carrier is good for VoLTE and just do it. So apparently Kogan Mobile somehow gives the Redmi 9A the impression that VoLTE isn t supported but if the phone just goes ahead and connects it will work. I don t plan to use a Redmi 9A myself as it s too slow, but I added it to my collection to offer to anyone else I know who needs a phone with VoLTE and doesn t use the phone seriously or to someone who needs a known good phone for testing things.
Samsung Galaxy Note 9
I got some Samsung Galaxy Note 9 phones to run Droidian as an experiment [7]. But Droidian dropped support for the Note 9 and I couldn t figure out how to enable VoLTE via Droidian, which was very annoying after I had spent $109 on a test phone and $215 on a phone for real use (I have no plans to try Droidian again at this time). I tried installing LineageOS on one Note 9 [8] which was much easier than expected (especially after previously installing Droidian). But VoLTE wasn t an option. According to Reddit LineageOS doesn t support VoLTE on Samsung devices and you can use a magisk module or a VoLTE enabler module but those aren t supported by LineageOS either [9].
I downloaded an original image for the Note 9 from SamsMobile.com [10]. That image booted past the orange stage (where if you have problems then your phone is probably permanently useless) but didn t boot into the OS. A friend helped me out with that and it turned out that the Heimdal flash tool on Linux didn t do something it needed to do and that Odin on Windows was required. After using Odin everything was fine and I have a Note 9 with VoLTE running the latest Samsung firmware which is security patch level 1st July 2022!!!
So I have a choice between using a Note 9 for data and SMS while running a current version of Lineage OS with all security fixes or running a Samsung image with no security updates for 2 years which supports phone calls. So based on this I have to recommend Pixel as the phone of choice, it has a decent level of support from Google and long term support from LineageOS. According to the LineageOS web site you can run the current version of Lineage on the original Pixel phone from 2016! Of course getting VoLTE to work on it might be another saga, but it would probably be easier to do with LineageOS on a Pixel than on a Samsung phone.
Conclusion
The operation of the Note 9 for me is decent now apart from the potential security issues. The same goes for selling one of the phones. The PinePhonePro still has potential to become my daily driver at some future time if I and others can optimise power use. Also a complicating factor is that I want to have both Jabber and Matrix be actually instant IM systems not IM with a 5 minute delay, so suspend mode isn t a good option.
Pixel phones will be a much higher priority when looking at phones to buy in future. The older Pixel phones go for as little as $100 on eBay and can still run the latest LineageOS.
VoLTE seems needlessly complicated.
A short status update of what happened on my side last month. Was able
to test our Cellbroadcast bits, feedbackd became more flexible
regarding LEDs, Phosh 0.40 is out, and some more.
Phosh
At home, I have both a laptop and a *desktop PC. Most of my essential
things, such as emails, repositories, password managers, contacts,
and calendars are synced between the two devices. However, when I
need to share some documents and I am lazy enough to go pick a flash
drive, my only option is to push them to the Internet and download
them on the other system, which is sitting at 20~ meters away.
Typically,
I do this either through email attachments or a matrix client.
Occasionally, I think about setting up a network storage solution at
home. But then I ask myself do I really need one.
In my home network, I already have a Raspberry Pi running as my Wi-Fi
router, doing DNS level ad blocking with Dnsmasq and DNS over TLS
with stubby. Rpi has a 16GB memory card. I can mount RPi remote
directory to both machines.
I use pcmanfm as my file manager. It has the ability (like every
other
file managers) to mount remote storage over ssh. But one annoying
thing is that whenever I open the mount directory,
by default it shows the root file system of the remote device even
when I explicitly mentioned the path.
Then I discovered sshfs. I wrote the following script, which mount
remote
directory and open that in pcmanfm.
I haven t enabled any encryption for the memory until now since other
than some logs RPi wasn t writing anything to it. I set up fscrypt on
Rpi storage now. And ta-da, a lazy person s local sharing solution.
*Desktop - Well, technically it s an old laptop with a broken
keyboard and trackpad, connected to a monitor, keyboard and mouse. I
don t feel keeping it on a shelf.
DebConf Bursary updates, by Utkarsh Gupta
Utkarsh is the bursaries team lead for DebConf 24. Bursary
requests are dispatched to a
team of volunteers to review. The results are collated, adjusted and merged to
produce priority lists of requests to fund. Utkarsh raised the team,
coordinated the review, and issued bursaries to attendees.
/usr-move, by Helmut Grohne
More and more, the /usr-move transition is being carried out by multiple
contributors and many performed around a hundred of the requested uploads. Of
these, Helmut contributed five patches and two uploads. As a result, there are
less than 350 packages left to be converted, and all of the non-trivial cases
have patches. We started with three times that number. Thanks to everyone
involved for supporting this effort.
For people interested in background information of this transition,
Helmut gave a presentation at MiniDebConf Berlin
2024
(slides).
sbuild, by Helmut Grohne
While unshare mode of sbuild has existed for quite a while, it is
now getting significant use in Debian, and new problems are popping up.
Helmut looked into an apparmor-related
failure and provided a diagnosis.
While relevant code would detect the chroot nature of a schroot
backend and skip apparmor tests, the unshare environment would be
just good enough to run and fail the test. As sbuild exposes fewer
special kernel filesystems, the tests will be skipped again.
Another problem popped up when gobject-introspection added a
dependency on the host architecture Python interpreter in a cross build
environment. sbuild would prefer installing (and failing) a host
architecture Python to installing the qemu alternative. Attempts to
fix this would result in systemd killing
sbuild. ischroot as used by
libc6.postinst would not classify the unshare environment as a
chroot. Therefore libc6.postinst would run telinit which would kill
the build process. This is a complex interaction problem that shall
eventually be solved by providing triggers from libc6 to be
implemented by affected init systems.
Salsa CI updates, by Santiago Ruano Rinc n
Several issues arose about Salsa CI last month, and it is probably worth
mentioning part of the challenges of defining its framework in YAML.
With the upcoming end-of-support of Debian 10 buster as LTS, armel was
removed from deb.debian.org, making the jobs that build images for
buster/armel to fail. While the removal of buster/armel from the
repositories is a natural change, it put some light on the flaws in
the Salsa CI design regarding the support of the different Debian
releases. Currently, the images are defined like these (from
.images-debian.yml):
Evidently, this increases duplication of the release support data, which
is of course not optimal and it is error prone when changing the data
about supported releases. A better approach would be to have two
different YAML lists, such as:
# releases that have partial support. E.g.: buster is transitioning to# Debian LTS, and buster armel is no longer found in deb.debian.org.old-releases: &old-releases - stretch - buster.currently-supported-releases: ¤tly-supported-releases - bullseye - bullseye-backports - bookworm - bookworm-backports - trixie - sid - experimental
that could be used in the matrix of the jobs that build all the images
available in the pipeline container registry.
However, due to limitations in
GitLab,
it is not possible to expand the variables or mapping values in a
parallel:matrix context. At least not in an elegant fashion.
This is the kind of issue that recently arose and that Santiago is
currently working to solve, in the simplest possible way.
Astute readers would notice that stretch is listed in the fully
supported releases. And there is no problem with stretch, because it is
built from archive.debian.org. Otto actually has tried to
fix
the broken image build job doing the same, but it is still incorrect,
because the security repository is not (yet) available in archive.debian.org.
Additionally, Santiago has also worked on other merge requests, such as:
Archiving DebConf Websites, by Stefano Rivera
DebConf, the annual Debian conference, has its own new website every
year. These are typically complex dynamic web applications (featuring
registration, call for papers, scheduling, etc.) Once the conference is
over, there is no need to keep maintaining these applications, so we
archive the sites off as static HTML, and serve them from Debian s
static CDN.
Stefano archived the websites for the last two DebConfs.
The schedule system behind DebConf 14
and 15 s websites was a derivative of
Canonical s summit
system. This was only used for a couple of years before migrating to
wafer, the current system. Archiving
summit content has been on the nice to have list for years, but nobody
has ever tackled it. The machine that served the sites went away a
couple of years ago. After much digging, a backup of the database was
found, and Stefano got this code running on an ancient Python 2.7.
Recently Stefano put this all together and hooked in an archive export
to finally get this content preserved.
Python 3.x and pypy3 security bug triage, by Stefano Rivera
Stefano Rivera triaged all the open security bugs against the Python 3.x
and PyPy3 packages for Debian s stable and LTS releases. Several had
been fixed but this wasn t recorded in the security tracker.
Linux livepatching support for Debian, by Santiago Ruano Rinc n
In collaboration with Emmanuel Arias, Santiago filed ITP bug
#1070494.
As stated in the bug, more than an Intent to Package, it is an Intent to
Design and Implement live patching support for the Linux kernel in
Debian. For now, Emmanuel and Santiago have done exploratory work and
they are working to understand the different possibilities to implement
livepatching. One possible direction is to rely on
kpatch, and the other is to
package the modules using regular packaging tools. Also, it is needed
to evaluate if it is possible to rely on distributing the modules via
packages, or instead as a service, as it is done by some commercial
distributions.
Miscellaneous contributions
Thorsten Alteholz uploaded cups-bjnp to improve packaging.
Colin Watson tracked down a baffling CI issue in openssh to unblock several merge requests, removed the user_readenv=1 option from its PAM configuration, and started on the first stage of his plan to split out GSS-API key exchange support to separate packages.
Colin did his usual routine work on the Python team, upgrading 26 packages to new upstream versions, and cherry-picking an upstream PR to fix a pytest 8 incompatibility in ipywidgets.
Colin NMUed a couple of packages to reduce the need for explicit overrides in Packages-arch-specific, and removed some other obsolete entries from there.
Emilio managed various library transitions, and helped finish a few of the remaining t64 transitions.
Helmut sent patches for 7 cross build failures, 6 other debian bugs and fixed an infrastructure problem in crossqa.debian.net.
Nicholas worked on a sponsored package upload, and discovered the blhc tool for diagnosing build hardening.
Stefano Rivera started and completed the re2 transition. The release team suggested moving to a virtual package scheme that includes the absl ABI (as re2 now depends on it). Adopted this.
Stefano continued to work on DebConf 24 planning.
Santiago continued to work on DebConf24 Content tasks as well as Debconf25 organisation.
University of Nairobi.
Our group at the conference.
View of Nairobi's skyline from the open area on the fifth floor.
A library in Mahatma Gandhi wing of the University of Nairobi.
One of the conference halls where talks took place.
One of the lunch meals served during the conference.
Minibus which took us from the university to Bao Box restaurant.
This minibus in the picture gave a sense of a real matatu.
Dear Debian community,
this are my bits from DPL for August.
Happy Birthday Debian
On 16th of August Debian celebrated its 31th birthday. Since I'm
unable to write a better text than our great publicity team I'm
simply linking to their article for those who might have missed it:
Another short status update of what happened on my side last month.
Quite a bit of time went
into helping organize the 
Conference Dinner Photo from Santiago
I've tried Android Element app for matrix first time during Debconf. It feels good. For me it's a better IRC.
I've been using it on my Chromebook and one annoyance is that I haven't found a keyboard shortcut for sending messages.
I would have expected shift or ctrl with Enter would send the current message, but so far I have been touching the display to send messages.
Can I fix this? Where is the code?
Here comes the 3rd article of the 5-episode blog post series on Polis, written by Guido Berh rster, member of staff at my company Fre(i)e Software GmbH.
Enjoy also this read on Guido's work on Polis,
