I'm Miles, also see: http://github.com/mil
My nick is mla on IRC.
From Miles Alan to ~mil/sxmo-devel
Nice to read everyone else's take too, I have some overlap in my painpoints. While I would love the Pinephone to be my daily driver, I admit its still currently an auxiliary phone for me. I know over time / eventually the Pinephone & Sxmo will win out in terms of reliability (as FOSS software always does), but its still maturing. Here's the main pain points for me (and things I should work on when I get some free time): - CRUST: TBH seems like reliability is in constant flux on pmOS, occasionally things freeze up. It's not difficult to fix these issues with the initcall_debug kernel param but its a pain to constantly have this inadvertently breaking. I'm tired of the instability.
From Miles Alan to ~mil/sxmo-devel
On Thu, Feb 25, 2021, at 4:53 PM, Jochen Sprickerhof wrote: > Calling timer_delete with an invalid timer is unspecified behavior so we > need to track of the timer was created before. See > > https://sourceware.org/pipermail/libc-alpha/2005-August/019335.html > > For a discussion. > > This fixes a segfault when linking with glibc. > --- > dwm.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) Hi Jochen - thanks for sending this by the way and glad Maarten has
From Miles Alan to ~mil/sxmo-devel
On Sun, Feb 28, 2021, at 9:51 AM, Serge E. Hallyn wrote: > On Sun, Feb 28, 2021 at 02:40:52AM -0500, Anjandev Momi wrote: > > > This doesn't give the application inside the window any chance to do anything > > > which, in the case of Firefox, causes the "restore session" message to pop-up > > > the next time it runs (but, for some reason, not always). > > > The original intent behind the force killwindow was that there are certain applications that will occasionally freeze up and don't obey SIGTERM / Shft-Alt-C. I've seen this happen with mpv in the past as well as firefox on musl on the Pinephone. I guess I wanted to err on the side of "always obeying the user" since normal killing occasionally can fail.
From Miles Alan to ~mil/sxmo-announce
Hi all, Just as a follow-up from Maarten's last email about the 1.3.0 release, I've triggered the CI to build a new image. The new 1.3.0 image is available at: http://images.lrdu.org/pinephone/ Also, an additional quick note.. pmOS is also now building weekly Sxmo images. The images built via pmOS's infra are really no different then our own CI which may eventually be deprecated but is remaining for now for immediate release testing and nightly testing around upcoming releases. The only thing to note is the default username / password is different for
From Miles Alan to ~mil/sxmo-devel
On Thu, Dec 31, 2020, at 8:24 AM, Maarten van Gompel wrote: > There were a few new upstream commits at suckless for dmenu, I now > integrated these into our tree. > > -- > > Maarten van Gompel (proycon) > https://proycon.anaproy.nl > Great - thanks for that. This does bring up the question of how to handle tagged versions after upstream version updates. The way sxmo tracks all forks for version numbers is sucklessversion.sxmoversion. E.g. for dmenu we forked off 4.9 and were at our 7th revision. So our last tag
From Miles Alan to ~mil/sxmo-devel
On Wed, Dec 30, 2020, at 4:15 AM, Maarten van Gompel wrote: > On 20-12-30 06:12, Anjandev Momi wrote: > > I have been using this patch for the past couple of days and it works > > perfectly. It especially improves the touch user experience on smaller > > ui elements (ie. files). > > > > The only thing left to decide is: do we want to have a environmental > > variable that will decide whether this is enabled? > > > > I like the patch as is and dont want to add more environmental variables > > but I won't merge until there has been sufficient discussion from the > > community. > > Great work! I think this patch is a definite improvement over the old
From Miles Alan to ~mil/sxmo-announce
Hi all, Just a quick note, a new image for the 1.2.0 release of Sxmo has been rolled. The the new 1.2.0 image is available at: http://images.lrdu.org/pinephone/ To see the full changelog for 1.2.0, reference Maarten's earlier announce email or check the generated changelog at: https://git.sr.ht/~mil/sxmo-docs/tree/master/CHANGELOG.md -- Note on versioning for the curious: In early versions we had been correlating sxmo-utils minor version numbers
From Miles Alan to ~mil/sxmo-devel
Anjandev Momi <anjan@momi.ca> wrote: > diff --git a/scripts/appscripts/sxmo_rss.sh b/scripts/appscripts/sxmo_rss.sh > index 2b50862..d298932 100755 > --- a/scripts/appscripts/sxmo_rss.sh > +++ b/scripts/appscripts/sxmo_rss.sh > @@ -1,8 +1,8 @@ > #!/usr/bin/env sh > FETCHENABLED=1 > > -if [ -f "$XDG_CONFIG_HOME/sxmo/sfeedrc" ]; then > - SFEEDCONF="$XDG_CONFIG_HOME/sxmo/sfeedrc" > +if [ -f "$XDG_DATA_HOME/sxmo/sfeedrc" ]; then > + SFEEDCONF="$XDG_DATA_HOME/sxmo/sfeedrc" > elif [ -f "$HOME/.sfeed/sfeedrc" ]; then
From to ~mil/sxmo-devel
From: Miles Alan <m@milesalan.com> --- scripts/modem/sxmo_modemmonitor.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/modem/sxmo_modemmonitor.sh b/scripts/modem/sxmo_modemmonitor.sh index bfb9916..16ef306 100755 --- a/scripts/modem/sxmo_modemmonitor.sh +++ b/scripts/modem/sxmo_modemmonitor.sh @@ -64,6 +64,7 @@ checkforincomingcalls() { grep -Eo '[0-9]+ incoming \(ringing-in\)' | grep -Eo '[0-9]+' )" [message trimmed]
From to ~mil/sxmo-devel
From: Miles Alan <m@milesalan.com> Use dbus to monitor for missed calls. Missed calls used to work but had a regression due to the work to make text/calls used dbus. This adds the proper dbus hook for missed calls as well and also changes the incoming call notification to allow for multiple incoming calls (theoretically). Tested for a single caller and transitioning the pickup notification into a missed call notification and all is working good. --- scripts/modem/sxmo_modemmonitor.sh | 20 +++++++++++++++++--- scripts/modem/sxmo_modemmonitortoggle.sh | 3 ++- 2 files changed, 19 insertions(+), 4 deletions(-) [message trimmed]