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 3 to make things bigger).

Related: #445

I tried out ~mungfusensei's sxmo_modemaudio.sh, and got it working after changing _card and _sink to grep -v out the _hdmi entries, 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 error recently 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)

~phartman Thoughts?

~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.

Using the @ 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.

We should

• 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