~aren

~aren/public-inbox

Last active 10 months ago
View more

Recent activity

Re: [PATCH sxmo-utils 1/2] move visual voicemail to a separate package 11 days ago

From Aren to ~mil/sxmo-devel

Oops... this is patch 1/1, not 1/2

[PATCH sxmo-utils 1/2] move visual voicemail to a separate package 11 days ago

From ArenM to ~mil/sxmo-devel

This is intended as an example of a method we could use to split sxmo-utils into
separate packages. I picked the vvm code because it was well separated, but this
technique should be applicale to other parts with a bit of work.

---
An example of a package using this can be found here
https://git.sr.ht/~aren/sxmo-utils-git-pkg/commit/9d0e5311f2bb529a517c9ca40aa2d17204f4686f#PKGBUILD

 Makefile                                      |  8 +++--
 .../default_hooks/sxmo_hook_contextmenu.sh    |  3 +-
 configs/default_hooks/sxmo_hook_start.sh      |  8 ++---
 scripts/modem/sxmo_modemmonitor.sh            | 33 -----------------
 scripts/{modem => voicemail}/sxmo_vvm.sh      |  0
 scripts/voicemail/sxmo_vvm_monitor.service    |  8 +++++
[message trimmed]

[PATCH sxmo-utils 2/2] contactmenu: add option to show formatted number 11 days ago

From ArenM to ~mil/sxmo-devel

I sometimes use the contacts menu to look up a number, when filling out
contact information on paper for example. Having the number formatted
makes it much easier to read.
---
 scripts/core/sxmo_contactmenu.sh | 26 +++++++++++++++++++++-----
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/scripts/core/sxmo_contactmenu.sh b/scripts/core/sxmo_contactmenu.sh
index 6ee1bb4..5d56e8c 100755
--- a/scripts/core/sxmo_contactmenu.sh
+++ b/scripts/core/sxmo_contactmenu.sh
@@ -5,7 +5,7 @@
# shellcheck source=configs/default_hooks/sxmo_hook_icons.sh
. sxmo_hook_icons.sh
[message trimmed]

[PATCH sxmo-utils 1/2] contactmenu: fix indentation 11 days ago

From ArenM to ~mil/sxmo-devel

---
 scripts/core/sxmo_contactmenu.sh | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/scripts/core/sxmo_contactmenu.sh b/scripts/core/sxmo_contactmenu.sh
index 3fe7c33..6ee1bb4 100755
--- a/scripts/core/sxmo_contactmenu.sh
+++ b/scripts/core/sxmo_contactmenu.sh
@@ -122,22 +122,22 @@ showcontact() {
	)"

	case "$PICKED" in
		 *"List Messages")
		*"List Messages")
[message trimmed]

Re: [PATCH sxmo-utils] Wait for fixed period of time for cron job 12 days ago

From Aren to ~mil/sxmo-devel

On Tue, Nov 08, 2022 at 05:03:51PM +0100, Stacy Harper wrote:
> > > Definitely not. Executing cronjob sometime take minutes or more. My wake
> > > up alarm can take up to 30mn…
> >
> > sxmo_rtcwake.sh also acquires a lock, this just forces the cron job to
> > start within 45s of waking from suspend. Your 30 minute alarm should be
> > safe.
>
> Nah I mean my fcron job take up to 30 minutes to trigger. This leave my
> phone in "waiting for cronjob" for way more than 45 seconds.

Oh I see now, that makes this much more difficult.

> > > We should instead findout why and fix the issue. We should also findout

Re: [PATCH sxmo-utils] tailtextlog: wrap lines at word boundaries 14 days ago

From Aren to ~mil/sxmo-devel

On Fri, Nov 18, 2022 at 10:57:48AM +0100, Stacy Harper wrote:
> I'm not really confident in doing this. First we then rely on tput. And
> second cause then the tail output cannot be resized. It means if you
> move your window, or rotate your screen, then the text is wrongly
> folded.

True, I guess this is probably better in sxmo-userscripts then, I'll
probably send a patch for that at some point.

[PATCH wvkbd] layout: fix open parenthesis on landscape layout 14 days ago

From ArenM to ~mil/sxmo-devel

This key had the wrong type, which was preventing it from sending a
character.
---
 layout.mobintl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/layout.mobintl.h b/layout.mobintl.h
index 7067ec2..7d52689 100644
--- a/layout.mobintl.h
+++ b/layout.mobintl.h
@@ -981,7 +981,7 @@ static struct key keys_landscape[] = {
  {"i", "I", 1.0, Code, KEY_I, &layouts[ComposeI]},
  {"o", "O", 1.0, Code, KEY_O, &layouts[ComposeO]},
  {"p", "P", 1.0, Code, KEY_P, &layouts[ComposeP]},
[message trimmed]

[PATCH sxmo-utils] tailtextlog: wrap lines at word boundaries 25 days ago

From ArenM to ~mil/sxmo-devel

---
 .../default_hooks/sxmo_hook_tailtextlog.sh    | 42 +++++++++++++------
 1 file changed, 30 insertions(+), 12 deletions(-)

diff --git a/configs/default_hooks/sxmo_hook_tailtextlog.sh b/configs/default_hooks/sxmo_hook_tailtextlog.sh
index a164ed6..d738186 100755
--- a/configs/default_hooks/sxmo_hook_tailtextlog.sh
+++ b/configs/default_hooks/sxmo_hook_tailtextlog.sh
@@ -8,15 +8,33 @@
# shellcheck source=scripts/core/sxmo_common.sh
. sxmo_common.sh

NUMBER="$1"
CONTACTNAME="$(sxmo_contacts.sh | grep ": ${NUMBER}$" | cut -d: -f1)"
[message trimmed]

Re: [PATCH sxmo-utils v2] Only alias compiled with busybox commands a month ago

From Aren to ~mil/sxmo-devel

It's simpler and much faster to remove these alises entirely and that
should only affect distros that don't use busybox by default.

On Tue, Nov 08, 2022 at 08:38:06AM +0100, Stacy Harper wrote:
> I added a SXMO_DISABLE_BUSYBOX for performance folks. I also stripped the grep in favor
> of an awk expression.

If you want to support disabling this then then we'll have to fix the
compatibility with non-busybox systems. IIUC the reason to have these
aliases is to avoid dealing with those issues, am I missing something?

It looks nicer without the grep, but I re-ran my benchmarks and it
performs almost identically.

Re: [PATCH sxmo-utils] Wait for fixed period of time for cron job a month ago

From Aren to ~mil/sxmo-devel

On Tue, Nov 08, 2022 at 08:42:12AM +0100, Stacy Harper wrote:
> Hey there,
> 
> Definitely not. Executing cronjob sometime take minutes or more. My wake
> up alarm can take up to 30mn…

sxmo_rtcwake.sh also acquires a lock, this just forces the cron job to
start within 45s of waking from suspend. Your 30 minute alarm should be
safe.

> We should instead findout why and fix the issue. We should also findout
> if there is case where the mutex isnt freed and fix this issue.

I haven't investigated too carefully, but I suspect our rtcwake call