Colors of Noise

agx@sigxcpu.org

Entries tagged "librem5".

Phosh 0.24.0 released
2nd February 2023

As the ecosystem around phosh continues to grow it can become harder for distributions and users to keep track of what actually makes up Phosh and what the current versions are. So let's spell out components and dependencies replacing the social media only announcements. The list is generated from the individual projects NEWS files and this was a good opportunity to automate the release process further. It looks like this now.

Edit (on 2023-03-09): Replaced the actual 0.24.0 release notes by a link to avoid confusion about the canonical location.

Tags: librem5, phosh.
Phosh 2022 in retrospect
31st December 2022

I wanted to look back at what changed in phosh in 2022 and figured I could share it with you. I'll be focusing on things very close to the mobile shell, for a broader overview see Evangelos upcoming FOSDEM talk.

Some numbers

We're usually aiming for a phosh release at the end of each month. In 2022 We did 10 releases like that, 7 major releases (bumping the middle version number) and three betas. We skipped the April and November releases. We also did one bug fix relesae out of line (bumping the last bit of the version number). I hope we can keep that cadence in 2023 as it allows us to get changes to users in a timely fashion (thus closing usability gaps as early as possible) as well as giving distributions a way to plan ahead. Ideally we'd not skip any release but sometimes real life just interferes.

Those releases contain code contributions from about 20 different people and translations from about 30 translators. These numbers are roughly the same as 2021 which is great. Thanks everyone!

In phosh's git repository we had a bit over 730 non-merge commits (roughly 2 per day), which is about 10% less than in 2021. Looking closer this is easily compensated by commits to phoc (which needed quite some work for the gestures) and phosh-mobile-settings which didn't exist in 2021.

User visible features

Most notable new features are likely the swipe gestures for top and bottom bar, the possibility to use the quick settings on the lock screen as well as the style refresh driven by Sam Hewitt that e.g. touched the modal dialogs (but also sliders, dialpads, etc):

Style Refresh Swipe up gesture

We also added the possibility to have custom widgets via loadable plugins on the lock screen so the user can decide which information should be available. We currently ship plugins to show

These are maintained within phosh's source tree although out of tree plugins should be doable too.

There's a settings application (the above mentioned phosh-mobile-settings) to enable these. It also allows those plugins to have individual preferences:

TODO A Plugin Plugin Preferenes

Speaking of configurability: Scale-to-fit settings (to work around applications that don't fit the screen) and haptic/led feedback are now configurable without resorting to the command line:

Scale to fit Feedbackd settings

We can also have device specific settings which helps to temporarily accumulate special workaround without affecting other phones.

Other user visible features include the ability to shuffle the digits on the lockscreen's keypad, a VPN quick settings, improved screenshot support and automatic high contrast theme switching when in bright sunlight (based on ambient sensor readings) as shown here.

As mentioned above Evangelos will talk at FOSDEM 2023 about the broader ecosystem improvements including GNOME, GTK, wlroots, phoc, feedbackd, ModemManager, mmsd, NetworkManager and many others without phosh wouldn't be possible.

What else

As I wanted a T-shirt for Debconf 2022 in Prizren so I created a logo heavily inspired by those cute tiger images you often see in Southeast Asia. Based on that I also made a first batch of stickers mostly distributed at FrOSCon 2022:

Phosh stickers

That's it for 2022. If you want to get involved into phosh testing, development or documentation then just drop by in the matrix room.


Tags: librem5, phosh, planetdebian, planetfsfe.
Kerberos authentication on the Librem 5
25th October 2022

The Librem 5 features a built-in smartcard reader. While most people use it for gpg I wanted to see if it can be used as an authenticator for services like email (SMTP, IMAP), access to web pages (HTTPS), calendars, etc without either having to retype a password often or having to store it on the device itself: single sign on for all my frequently used services.

Librem 5's smart card reader

For that one can leverage a feature called PKINIT of Kerberos (a network authentication protocol meant to allow secure communication over a non-secure network) which uses public key cryptography for initial user authentication (instead of a password). If the key material is saved on the smart card even a lost device can hardly be abused as the smart card is protected by a PIN and will lock itself after three incorrect tries (and you can easily revoke the certificate server side too).

On the service side one can use SASL/GSSAPI to make services like exim, postfix, dovecot, cyrus imapd, apache, nginx or prosodi use Kerberos to authenticate users and there's many more (like CalDAV servers, etc). The most prominent missing bit for me is currently the Synapse matrix server not supporting GSSAPI yet.

I won't go into the details of setting up the Kerberos server (KDC) or PKINIT itself or how to configure services as this is already done elsewhwere (1, 2) but rather focus on the Librem 5 and smart card side.

So for the following let's assume you have a Kerberos realm called MS20.NIX set up and your KDC has the DNS name kdc.ms20.nix, and your Kerberos principal (your user in the Kerberos database) is called foo@MS20.NIX. You also have an smtp and imap servers called smtp.ms20.nix and imap.ms20.nix set up to autenticate users via Kerberos. Finally we call the CA that signs all your certificates ca.pem (were're following the naming from 2).

What follows looks as if lots of things need to be done on the command line. I'll show a simplification at the very end but wanted those bits written down for reference/debugging. Note that this post is not meant as an exhaustive introduction but more like a quick summary of commands. I'm happy if someone grabs it and adds more details.

Kerberos Setup on the Librem 5

Let's first install the Kerberos client side packages on the phone and test that:

$ sudo apt install heimdal-clienets

The krb5-config package will ask for your Kerberos realm, KDC etc. With that in place you should be able to test if you can get a Kerberos ticket via

$ kinit

and entering your password.

If that worked the klist output will look something like:

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: foo@MS20.NIX

Issued                Expires               Principal
Oct 24 12:55:13 2022  Oct 25 12:55:13 2022  krbtgt/MS20.NIX@MS20.NIX

Now that basic authentication worked We're ready to switch to certificates stored them on the smart card. Let's drop the credentials first:

$ kdestroy

Smartcard Setup

I have used an OpenPGP card smartcard and inserted that into the Librem 5. In my case it was salvaged from a Librem Key. As PKINIT uses OpenSC the OpenSC wiki was very helpful as it has details on how to get key material onto that particular card.

The software to use the Librem 5's smart card reader is enabled by default as part of the librem5-base package. You just need to add opensc to the mix:

$ sudo apt install opensc

With that you should already be able to see the card:

$ opensc-tool -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             L5 built-in SmartCard Reader 00 01 00 00
1    Yes             L5 built-in SmartCard Reader 00 01 00 01

As there's only a single reader and the second entry can confuse opensc let's ignore that one:

$ cat <<EOF > /etc/opensc/opensc.conf
app default {
    ignored_readers = "TTXS serial 00 01 00 01","L5 built-in SmartCard Reader 00 01 00 01"
}
EOF

Which should make the output look like

$ opensc-tool -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             L5 built-in SmartCard Reader 00 01 00 00

With the reader up and running we can now store the certificate and private key on it. For simplicity we create these on the KDC and transfer them to the phone (a more realistic setup would create those locally and use a certificate signing request so the private key never leaves your hands):

On the KDC:

$ hxtool issue-certificate --ca-certificate=FILE:krbca.pem --generate-key=rsa --key-bits=2048 --type="pkinit-client" --pk-init-principal="foo@MS20.NIX" --subject="uid=foo,DC=ms20,DC=nix" --certificate="FILE:user.pem"

Then you'd copy the file to your phone and install certificate and private key on the smartcard like (this will delete any already existing keys on the card):

$ # Install needed packages
$ sudo apt install opensc wipe
$ # Delete old keys and install certificate and private key on smartcard
$ pkcs15-init --delete-objects privkey,pubkey,cert --id 1 --auth-id 3
$ pkcs15-init --delete-objects privkey,pubkey,cert --id 2 --auth-id 3
$ pkcs15-init --delete-objects privkey,pubkey,cert --id 3 --store-private-key user.pem  --store-certificate user.pem --id 3 --auth-id 3
$ # Wipe the file containing the private key
$ wipe user.pem

Afterward we can look at what's on the card

$ pkcs15-tool -D
Using reader with a card: L5 built-in SmartCard Reader 00 01 00 00
PKCS#15 Card [OpenPGP card]:
  Version        : 0
  Serial number  : <serial number>
  Manufacturer ID: ZeitControl
  Language       : de
  Flags          : PRN generation, EID compliant


PIN [User PIN]
  Object Flags   : [0x03], private, modifiable
  Auth ID        : 03
  ID             : 02
  Flags          : [0x13], case-sensitive, local, initialized
  Length         : min_len:6, max_len:64, stored_len:64
  Pad char       : 0x00
  Reference      : 2 (0x02)
  Type           : UTF-8
  Path           : 3f00
  Tries left     : 3

PIN [User PIN (sig)]
  Object Flags   : [0x03], private, modifiable
  Auth ID        : 03
  ID             : 01
  Flags          : [0x13], case-sensitive, local, initialized
  Length         : min_len:6, max_len:64, stored_len:64
  Pad char       : 0x00
  Reference      : 1 (0x01)
  Type           : UTF-8
  Path           : 3f00
  Tries left     : 3

PIN [Admin PIN]
  Object Flags   : [0x03], private, modifiable
  ID             : 03
  Flags          : [0x9B], case-sensitive, local, unblock-disabled, initialized, soPin
  Length         : min_len:8, max_len:64, stored_len:64
  Pad char       : 0x00
  Reference      : 3 (0x03)
  Type           : UTF-8
  Path           : 3f00
  Tries left     : 3

Private RSA Key [Authentication key]
  Object Flags   : [0x03], private, modifiable
  Usage          : [0x222], decrypt, unwrap, nonRepudiation
  Access Flags   : [0x1D], sensitive, alwaysSensitive, neverExtract, local
  Algo_refs      : 0
  ModLength      : 2048
  Key ref        : 2 (0x02)
  Native         : yes
  Auth ID        : 02
  ID             : 03
  MD:guid        : 135c302c-ddad-1a3c-f558-8beae7612f9f

Public RSA Key [Authentication key]
  Object Flags   : [0x02], modifiable
  Usage          : [0x51], encrypt, wrap, verify
  Access Flags   : [0x02], extract
  ModLength      : 2048
  Key ref        : 0 (0x00)
  Native         : no
  Path           : a401
  ID             : 03

X.509 Certificate [Cardholder certificate]
  Object Flags   : [0x00]
  Authority      : no
  Path           : 3f007f21
  ID             : 03
  Encoded serial : <serial>

The OpenPGP card's default admin PIN is 12345678 and the user pin 123456.

PKINIT Setup

Now add

[libdefaults]
pkinit_anchors = FILE:/etc/ssl/certs/ca.pem

to your /etc/krb5.conf and place the ca.pem in /etc/ssl/certs. With that you should be able to use pkinit. The -C option tells kinit to use your smart card for the crypto:

$ kinit -C PKCS11:/usr/lib/aarch64-linux-gnu/pkcs11/onepin-opensc-pkcs11.so foo@MS20.NET
PIN code for L5 built-in SmartCard Reader 00 01 00 00:

After entering the pin and typing klist the output should be similar to the klist output above. If you connect to various Kerberized services in your realm (e.g. by sending mail) the list will grow without having to retype any PINs or passwords:

$ klist
Credentials cache: FILE:/tmp/krb5cc_1000
        Principal: foo@ms20.nix

  Issued                Expires               Principal
Oct 24 12:55:13 2022  Oct 25 12:55:13 2022  krbtgt/MS20.NIX@MS20.NIX
Oct 24 12:55:57 2022  Oct 25 12:55:13 2022  imap/imap.ms20.nix@
Oct 24 12:57:45 2022  Oct 25 12:55:13 2022  smtp/smtp.ms20.nix@
Oct 24 13:00:32 2022  Oct 25 12:55:13 2022  HTTP/http.ms20.nix@

Can we make this simpler?

The above is very command line heavy and thus hard to use on a phone. With krb5-auth-dialog things become easier to set up. There's no need to adjust /etc//krb5.conf or to copy any certificates. PKINIT via smartcard is being enabled by a single click and you can select your CA (KDC trust anchor) via UI too:

PKINIT setup PIN dialog

There's a graphical dialog to enter your PIN that can either be started via the menu or triggered via a simple DBus call:

 $ gdbus call -e -d org.gnome.KrbAuthDialog -o /org/gnome/KrbAuthDialog -m org.gnome.KrbAuthDialog.acquireTgt ''

and the good part is that it won't prompt you if you already have a valid ticket. So you can e.g. add this as a hook to your offlineimap config.

As far as I know there's no end user friendly tool to transfer the certificates to the smartcard yet but note that this doesn't even have to happen on the phone itself. You can provision those elsewhere and then add the card to the phone but it might make sense to add that functionality to either krb5-auth-dialog or seahorse.

I hope this post motivates people to try this out and to leverage Kerberos for authenticating to services via the Librem 5's built-in smartcard reader.

Pitfalls


Tags: gnome, librem5, phosh, single-sign-on.
On a road to Prizren with a Free Software Phone
12th August 2022

Since people are sometimes slightly surprised that you can go onto a multi week trip with a smartphone running free sofware so only I wanted to share some impressions from my recent trip to Prizren/Kosovo to attend Debconf 22 using a Librem 5. It's a mix of things that happend and bits that got improved to hopefully make things more fun to use. And, yes, there won't be any big surprises like being stranded without the ability to do phone calls in this read because there weren't and there shouldn't be.

After two online versions Debconf 22 (the annual Debian Conference) took place in Prizren / Kosovo this year and I sure wanted to go. Looking for options I settled for a train trip to Vienna, to meet there with friends and continue the trip via bus to Zagreb, then switching to a final 11h direct bus to Prizren.

When preparing for the trip and making sure my Librem 5 phone has all the needed documents I noticed that there will be quite some PDFs to show until I arrive in Kosovo: train ticket, bus ticket, hotel reservation, and so on. While that works by tapping unlocking the phone, opening the file browser, navigating to the folder with the PDFs and showing it via evince this looked like a lot of steps to repeat. Can't we have that information on the Phone Shell's lockscreen?

This was a good opportunity to see if the upcoming plugin infrastructure for the lock screen (initially meant to allow for a plugin to show upcoming events) was flexible enough, so I used some leisure time on the train to poke at this and just before I reached Vienna I was able to use it for the first time. It was the very last check of that ticket, it also was a bit of cheating since I didn't present the ticket on the phone itself but from phosh (the phones graphical shell) running on my laptop but still.

PDF barcode on phosh's lockscreen List of tickets on phosh's lockscreen

This was possible since phosh is written in GTK and so I could just leverage evince's EvView. Unfortunately the hotel check in didn't want to see any documents ☹.

For the next day I moved the code over to the Librem 5 and (being a bit nervous as the queue to get on the bus was quite long) could happily check into the Flixbus by presenting the barcode to the barcode reader via the Librem 5's lockscreen.

When switching to the bus to Prizren I didn't get to use that feature again as we bought the tickets at a counter but we got a nice krem banana after entering the bus - they're not filled with jelly, but krem - a real Kosovo must eat!).

Although it was a rather long trip we had frequent breaks and I'd certainly take the same route again. Here's a photo of Prizren taken on the Librem 5 without any additional postprocessing:

Prizren

What about seeing the conference schedule on the phone? Confy(a conferences schedule viewer using GTK and libhandy) to the rescue:

Confy with Debconf's schedule

Since Debian's confy maintainer was around too, confy saw a bunch of improvements over the conference.

For getting around Puremaps(an application to display maps and show routing instructions) was very helpful, here geolocating me in Prizren via GPS:

Puremaps

Puremaps currently isn't packaged in Debian but there's work onging to fix that (I used the flatpak for the moment).

We got ourselves sim cards for the local phone network. For some reason mine wouldn't work (other sim cards from the same operator worked in my phone but this one just wouldn't). So we went to the sim card shop and the guy there was perfectly able to operate the Librem 5 without further explanation (including making calls, sending USSD codes to query balance, …). The sim card problem turned out to be a problem on the operator side and after a couple of days they got it working.

We had nice, sunny weather about all the time. That made me switch between high contrast mode (to read things in bright sunlight) and normal mode (e.g. in conference rooms) on the phone quite often. Thankfully we have a ambient light sensor in the phone so we can make that automatic.

Phosh in HighContrast

See here for a video.

Jathan kicked off a DebianOnMobile sprint during the conference where we were able to improve several aspects of mobile support in Debian and on Friday I had the chance to give a talk about the state of Debian on smartphones. pdf-presenter-console is a great tool for this as it can display the current slide together with additional notes. I needed some hacks to make it fit the phone screen but hopefully we figure out a way to have this by default.

Debconf talk Pdf presenter console on a phone

I had two great weeks in Prizren. Many thanks to the organizers of Debconf 22 - I really enjoyed the conference.

Tags: debian, gnome, librem5, phosh, planetdebian, planetfsfe, planetgnome.
phosh overview
28th December 2020

For a slightly more up to date version see here

phosh is graphical shell for mobile, touch based devices like smart phones. It's the default graphical shell on Purism's Librem 5 (and that's where it came to life) but projects like postmarketOS, Mobian and Debian have picked it up putting it into use on other devices as well and contributing patches.

This post is meant as a short overview how things are tied together so further posts can provide more details.

A PHone SHell

As mobile shell phosh provides the interface components commonly found on mobile devices to

phosh's overview 2 phosh's lockscreen phosh's overview 1

It uses GObject object system and GTK to build up the user interface components. Mobile specific patterns are brought in via libhandy.

Since phosh is meant to blend into GNOME as seamlessly as possible it uses the common interfaces present there via D-Bus like org.gnome.Screensaver or org.gnome.keyring.SystemPrompter and retrieves user configuration like keybindings via GSettings from preexisting schema.

The components of a running graphical session roughly look like this:

phosh session

The blue boxes are the very same found on GNOME desktop sessions while the white ones are currently only found on phones.

feedbackd is explained quickly: It's used for providing haptic or visual user feedback and makes your phone rumble and blink when applications (or the shell) want to notify the user about certain events like incoming phone calls or new messages. What about phoc and squeekboard?

phoc and squeekboard

Although some stacks combine the graphical shell with the display server (the component responsible for drawing applications and handling user input) this isn't the case for phosh. phosh relies on a Wayland compositor to be present for that. Keeping shell and compositor apart has some advantages like being able to restart the shell without affecting other applications but also adds the need for some additional communication between compositor and shell. This additional communication is implemented via Wayland protocols. The Wayland compositor used with phosh is called phoc for PHone Compositor.

One of these additional protocols is wlr-layer-shell. It allows the shell to reserve space on the screen that is not used by other applications and allows it to draw things like the top and bottom bar or lock screen. Other protocols used by phosh (and hence implemented by phoc) are wlr-output-management to get information on and control properties of monitors or wlr-foreign-toplevel-management to get information about other windows on the display. The later is used to allow to switch between running applications.

However these (and other) Wayland protocols are not implemented in phoc from scratch. phoc leverages the wlroots library for that. The library also handles many other compositor parts like interacting with the video and input hardware.

The details on how phoc actually puts things up on the screen deserves a separate post. For the moment it's sufficient to note that phosh requires a Wayland compositor like phoc.

We've not talked about entering text without a physical keyboard yet - phosh itself does not handle that either. squeekboard is the on screen keyboard for text (and emoji) input. It again uses Wayland protocols to talk to the Wayland compositor and it's (like phosh) a component that wants exclusive access to some areas of the screen (where the keyboard is drawn) and hence leverages the layer-shell protocol. Very roughly speaking it turns touch input in that area into text and sends that back to the compositor that then passes it back to the application that currently gets the text input. squeekboard's main author dcz has some more details here.

The session

So how does the graphical session in the picture above come into existence? As this is meant to be close to a regular GNOME session it's done via gnome-session that is invoked somewhat like:

phoc -E 'gnome-session --session=phosh'

So the compositor phoc is started up, launches gnome-session which then looks at phosh.session for the session's components. These are phosh, squeekboard and gnome-settings-daemon. These then either connect to already running services via D-Bus (e.g. NetworkManager, ModemManager, ...) or spawn them via D-Bus activation when required (e.g. feedbackd).

Calling conventions

So when talking about phosh it's good to keep several things apart:

On top of that people sometimes refer to 'Phosh' as the software collection consisting of the above plus more components from GNOME (Settings, Contacs, Clocks, Weather, Evince, ...) and components that currently aren't part of GNOME but adapt to small screen sizes, use the same technologies and are needed to make a phone fun to use e.g. Geary for email, Calls for making phone calls and Chats for SMS handling.

Since just overloading the term Phosh is confusing GNOME/Phosh Mobile Environment or Phosh Mobile Environment have been used to describe the above collection of software and I've contacted GNOME on how to name this properly, to not infringe on the GNOME trademark but also give proper credit and hopefully being able to move things upstream that can live upstream.

That's it for a start. phosh's development documentation can be browsed here but is also available in the source code.

Besides the projects mentioned above credits go to Purism for allowing me and others to work on the above and other parts related to moving Free Software on mobile Linux forward.

Tags: librem5, phosh, planetdebian, planetgnome.
Introducing gtherm
7th January 2020

Continuous temperature monitoring from the kernel's /sys/class/thermal/ in an application can be cumbersome. gtherm aims to make that simpler by providing a daemon (gthd) that exports thermal zones and cooling cells over DBus and providing a small library libgtherm (and GObject introspection bindings). gthcli is a simple command line client that displays the currently found values:

Thermal Zones
-------------
      dbus path: /org/sigxcpu/Thermal/ThermalZone/0
           type: cpu-thermal
    temperature: 53,00°C
cooling devices: /org/sigxcpu/Thermal/CoolingDevice/0

      dbus path: /org/sigxcpu/Thermal/ThermalZone/3
           type: max170xx_battery
    temperature: 36,60°C

      dbus path: /org/sigxcpu/Thermal/ThermalZone/2
           type: vpu-thermal
    temperature: 54,00°C

      dbus path: /org/sigxcpu/Thermal/ThermalZone/1
           type: gpu-thermal
    temperature: 54,00°C
cooling devices: /org/sigxcpu/Thermal/CoolingDevice/1

Cooling Devices
---------------
    dbus path: /org/sigxcpu/Thermal/CoolingDevice/0
         type: thermal-idle-0
    max state: 100
current state: 0

    dbus path: /org/sigxcpu/Thermal/CoolingDevice/1
         type: 38000000.gpu
    max state: 6
current state: 0

There's support for gnome-usage in the works:

gnome-usage thermal view

Next up is support for trip points (and maybe tuning cooling behaviour from userspace later on).

Tags: gnome, librem5, phosh, planetgnome.
GTK+ and the application id
28th August 2018

tl;dr: If you want to be sure your application will be displayed with the correct icon under different Wayland compositors make sure that your GApplication (or GtkApplication) uses

g_set_prgname(your_g_application_id);

on GTK+3. On GTK+4 this is handled for you.

Details: While working on touch based window switching for the Librem5 I noticed that lots of the GNOME application did not end up with a proper icon when using g_desktop_app_info_new (desktop_id). The desktop_id is determined from the Wayland xdg surface's app_id as specified by in Wayland's xdg-shell protocol.

The protocol says:

The compositor shell will try to group application surfaces together
by their app ID. As a best practice, it is suggested to select app
ID's that match the basename of the application's .desktop file.
For example, "org.freedesktop.FooViewer" where the .desktop file is
"org.freedesktop.FooViewer.desktop".

It's even more explicit about the relation of the app_id to the D-Bus service name:

For D-Bus activatable applications, the app ID is used as the D-Bus
service name.

So why does this currently fail? It's because GTK+3 historically uses g_get_prgname() to set the app_id and this defaults to application's basename. But what we rather want is

g_application_id == D-Bus service name == $(basename desktop_file_path .desktop) == xdg app_id

There were patches by Jonas Ådahl to fix this but those were partially reverted since it broke existing applications. Now with GTK+4 around the corner we can fix this. See the migration docs.

This will also allow us to get rid of all the rename-desktop-file in the flatpak manifests too.

(The reason why this currently works in gnome-shell is because there's a private protocoll between GTK+ and GNOME Shell that (among other things) works around this).

Update: to check what app_id Wayland is seeing use:

WAYLAND_DEBUG=1 your_program |& grep 'xdg_toplevel@[0-9]\+\.set_app_id'
Tags: librem5, phosh, planetdebian, planetgnome.
libhandy 0.0.2
24th July 2018

Last month we tagged the first release of libhandy, a GTK+ library to ease the development of GNOME applications for mobile devices and small screens. Two of the contained widgets, HdyLeaflet and HdyColumn, are containers to address the specific size constraints of phones (video by Adrien). The rest are special purpose widgets, needed more than once on mobile devices, e.g. a Keypad (video).

This time around for the v0.0.2 release we mostly have bugfixes. From the Debian package's changelog:

[ Adrien Plazas ]
* dialer: Make the grid visible and forbid show all.
* example: Drop usage of show_all()
* dialer: Add column-spacing and row-spacing props.
* example: Change the grid's spacing and minimum size request.
* flatpak: Allow access to the dconf config dir.
* Replace phone-dial-symbolic by call-start-symbolic.
* column: Fix height for width request.

[ Guido Günther ]
* Use source.puri.sm instead of code.puri.sm.
* Add AUTHORS file
* gitlab-ci: Build on Debian buster using provided build-deps.
* arrows: test object construction
* Multiple gtk-doc fixes
* docs: Abort on warnings.
* DialerButton: free letters

The Debian package was uploaded to Debian's NEW queue.

Tags: librem5, planetdebian, planetgnome.

RSS Feed