West Michigan, USA
We start, around the turn of the millenium, with a dot on the map: a small city where tickets to the local cinema cost only two dollars. Just outside city limits sat a parsonage, inwhich memorable history was being formed:
"That's so easy, even Zach can read it!" called one of the others.
Now, others there were, in contrast to the big people, who, here, seemed to run the joint by joint-ownership.
I was beckoned toward a newspaper, where a three-panel cartoon was being indicated.
"Here, read this!"
My first test of skill... would I succeed, proving my capability, or fail, showing the known universe that I was most inferior.
Panel 1: Garfield sits on the counter, saying "Zzzzzzzz" Panel 2: Garfield is still sitting on the counter, Jon is watching. Garfield says "Zzzzzzzz" Panel 3: Jon breaks the pattern of Zee's, and says ________...
I couldn't do it. I was the only person who didn't know how to read.
Some times I find it easy to hit the right thing, and other times not.
We've already changed the pickup call menu to avoid fat-fingering, maybe we should have a "driving mode", where UI elements are just larger? (Or I guess I could do
swaymsg output '*' scale 3to make things bigger).
I tried out ~mungfusensei's sxmo_modemaudio.sh, and got it working after changing
grep -vout the
_hdmientries, and changing "VoiceCall" to "Voice Call". (I'm using pipewire, if that's relevant).
It seemed to work fine for receiving a call, and switching back/forth between speaker phone/earpiece, but when I plugged in headphones, nothing worked any more. (it should be noted that callaudiod was still running in the background, just not sure what exactly it does anyway.)
Can we encrypt it with the user's private ssh key? (But maybe that wouldn't make sense for editing it by hand?)
Alternatively, https://sr.ht/~grmat/otf-statusbar/ might be an easier project to use instead (though creating new icons requires an SVG editor, not quite as "simple" as my project).
Currently this has icons relevant to status bar.
I started a project with my approach to replacing Nerd Fonts as described above, and it's at the point where others can help if they're interested.
I call it Simple Ⅹ✕Ⅹ Mobile Icons (because the icons are made on a 10 by 10 grid: I'm not trying to assert some officiality yet).
The switch away from a bitmap layer helped, but the artifacts seen in https://gitlab.com/bztsrc/scalable-font2/-/issues/19 are still an issue.
Optimizing the vector layers would solve.
I've also been getting
rtcwake: write errorrecently when I try to run
rtcwake -m mem -s 60. (PinePhone 1.2 on linux 5.17.0-rc8). It's sets the alarm, but fails to suspend. -m disk and -m freeze similarly fail.
If I use
-m off, then it actually works, except for the part about waking itself up.
Note: I've never had a pleasant crust experience on this device (lengthy reboot required, never have had it "resume" from suspend using anything but the power button), so I'm not really sure how it's supposed to work.
In master, suspending from the menu is broken, since sxmo_hook_crust.sh no longer exists.
Maybe we should use sxmo_suspend.sh or sxmo_hook_suspend.sh (See c15fb89)
~hyppo's issue may be something like https://todo.sr.ht/~mil/sxmo-tickets/442 and/or a device related issue: Does the poweroff lead to reboot when using other interfaces?
I couldn't find any conventions for specification of branch. Patchwork doesn't even have a convention for specification of target-repo, but patchwork's documentation does say
it's also possible to have multiple projects in the same list using the subject as filter.
Their subject_match code allows defining arbitrary regular expressions to match the project when a list has multiple projects, so there's lots of customizability allowed here.
The only alternative I could think of would be
[PATCH repo-name@branch-name v2 1/2]. (It's unlikely a repository name would contain an
@, though we are already using space as a separator.)
Ideally, we'd want something that can be used easily with
git send-email, but it doesn't seem like they have anything made for this.
@sign would give a shorter way of defining the subject for a list that only has one project: e.g.
[PATCH @branch v3 0/3]. This would also remove ambiguity of sending a patch to a branch named "v3".
Currently, hub.sr.ht submits a job for any patch sent to a mailing list for a repo with a build manifest, but _apply_patch will only target the default branch, so developing on multiple branches is more difficult.
- determine a good way to specify target branch (maybe
[PATCH repo-name branch-name v2 1/2]: check if other conventions exist first)
- patch hub to handle this
- make sure lists can handle this