The Netherlands
I do computer stuff
From Martijn Braam to ~martijnbraam/public-inbox
Thanks, applied :) On 2/13/23 17:14, psykose wrote: > from https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location : > > Upstream projects can ship one or more metainfo files in /usr/share/ > metainfo/%{id}.metainfo.xml, > --- > > apparently reading is hard- the filename gets renamed too. > > data/meson.build | 6 +++--- > ...appdata.xml.in => nl.brixit.Thumbdrives.metainfo.xml.in} | 0 > 2 files changed, 3 insertions(+), 3 deletions(-)
From Martijn Braam to ~martijnbraam/public-inbox
Thanks, applied :) On 2/2/23 16:42, ~lihis wrote: > Appstream data validation fails with "appstream-util validate-relax > --nonet" as there is two <release>'s with same version. This patch > removes the duplicate entry thus making the validation to pass. > > Tomi Lähteenmäki (1): > Remove duplicate version from appstream data > > data/org.postmarketos.Numberstation.appdata.xml | 10 +--------- > 1 file changed, 1 insertion(+), 9 deletions(-) >
From Martijn Braam to ~martijnbraam/public-inbox
Hi Andrey, Sorry for the delay, I've applied your patches. I had not encountered otp urls with decimals in them before, they don't really make sense for things like length but better to handle it than not I guess. Greetings, Martijn Braam On 1/14/23 11:33, Andrey Skvortsov wrote: > Hi Martijn, > > Do you have any feedback on these patches sent a month ago?
From Martijn Braam to ~martijnbraam/public-inbox
Thanks, applied :) On 2/22/23 17:15, Evangelos Ribeiro Tzaras wrote: > The icon was introduced in > ffa0b6a57ebed3f851d79723862c82bc927ff732 > but never actually used (user-trash-symbolic is used instead). > --- > numberstation/icon/delete-symbolic.svg | 1 - > numberstation/numberstation.gresource.xml | 2 -- > 2 files changed, 3 deletions(-) > delete mode 100644 numberstation/icon/delete-symbolic.svg > > diff --git a/numberstation/icon/delete-symbolic.svg b/numberstation/icon/delete-symbolic.svg > deleted file mode 100644
From Martijn Braam to ~martijnbraam/public-inbox
Thanks, applied :) On 2/22/23 11:15, Hugo Osvaldo Barrera wrote: > Many projects add a leading `v` to tags for versions. However, the > contents of tarballs don't include this, so `$builddir` ends up being > `package-v1.0.0`, but the real path is actually `package-1.0.0`. > > I haven't seem any scenarios where a leading `v` is present but this > doesn't uphold. > > That aside, APKBUILD conventions seem to align with removing the leading > `v`. > --- > createaport/forge.py | 4 ++++
From Martijn Braam to ~postmarketos/pmbootstrap-devel
It's possible to set the default To: address and subject prefix in the git config of the local checkout. This makes the workflow a bit easier and makes sure the subject starts with [PATCH pmbootstrap] instead of the regular [PATCH]. --- README.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/README.md b/README.md index 005e7bc1..de3554f3 100644 --- a/README.md +++ b/README.md @@ -17,6 +17,12 @@ Send patches via mail or web UI to ~postmarketos/pmbootstrap-devel@lists.sr.ht [message trimmed]
From Martijn Braam to ~martijnbraam/public-inbox
This behavior is because it's title-casing it with a few exceptions. https://git.sr.ht/~martijnbraam/keyring/tree/master/item/himitsu_gtk/window.py#L83 I did not account for imaps vs imap here, mainly there's not really a spec for this part. The title casing works a lot better with everything that's not an acronym like the web protocol. On 10/22/22 01:59, Hugo Osvaldo Barrera wrote: > For some odd reason, the casing of the protocol "titles" (e.g.: the labels on > the top of each protocol) is mixed up; the first one is shown all uppercase > ("SMTP"), while others are title-case ("Imaps", "Smtps", etc). > > A screenshot might be much clearer, but emails with image/png attachment are
From Martijn Braam to ~calebccff/pbsplash
On 7/6/22 15:06, Caleb Connolly wrote: > > > On 05/07/2022 17:10, Martijn Braam wrote: >> Make the types for variables more consistent to limit casts. All >> physical dimensions are floats and pixel coordinates are long except on >> the interface with tflib which uses int. > Out of interest, why use long for pixel coordinates instead of int? Do > any values get close to exceeding INT_MAX? they don't, but on ARM int and long are both 32 bits. since most C apis dealing with numbers give long as result making all the coordinates consistently long makes most of the code a bit neater. the (int)somelong casts are no-ops on the ARM builds when checking with
From Martijn Braam to ~calebccff/pbsplash
Make the types for variables more consistent to limit casts. All physical dimensions are floats and pixel coordinates are long except on the interface with tflib which uses int. --- include/pbsplash.h | 2 +- src/animate.c | 30 +++++++++------ src/pbsplash.c | 96 ++++++++++++++++++++++------------------------ 3 files changed, 65 insertions(+), 63 deletions(-) diff --git a/include/pbsplash.h b/include/pbsplash.h index b855f28..423f128 100644 --- a/include/pbsplash.h +++ b/include/pbsplash.h @@ -10,6 +10,6 @@ struct col { [message trimmed]
From Martijn Braam to ~calebccff/pbsplash
There are boot flow mockups on https://gitlab.com/postmarketOS/pmaports/-/issues/1356 My proposal: 1. Add an unix socket to pbsplash that is listened on for commands while it's displaying the splash screen in the initfs 2. Create a pbctl utility to send messages to that socket to update the screen There would be 4 different states for the UI that can be switched to with pbctl: