~earboxer

West Michigan, USA

https://zachdecook.com

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.

Trackers

~earboxer/sxmo-icons

Last active a month ago

#484 bemenu height default to 30 from 20 4 days ago

Comment by ~earboxer on ~mil/sxmo-tickets

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

#502 "We failed to reset call audio" 4 days ago

Comment by ~earboxer on ~mil/sxmo-tickets

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

#39 wizard: the fact that the password is stored in plaintext is not obvious a month ago

Comment by ~earboxer on ~rjarry/aerc

Can we encrypt it with the user's private ssh key? (But maybe that wouldn't make sense for editing it by hand?)

#426 some icons in nerd fonts display wrong a month ago

Comment by ~earboxer on ~mil/sxmo-tickets

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.

#426 some icons in nerd fonts display wrong a month ago

Comment by ~earboxer on ~mil/sxmo-tickets

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

#1 Fix overlapping segments rendering bug a month ago

Ticket created by ~earboxer on ~earboxer/sxmo-icons

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.

issue when using bitmap layer Icon state

#442 Crust suspend is broken a month ago

Comment by ~earboxer on ~mil/sxmo-tickets

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.

#478 poweroff, suspend doesn't work correctly a month ago

Comment by ~earboxer on ~mil/sxmo-tickets

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?

#82 Submit builds jobs for patches targeting a specific branch 2 months ago

Comment by ~earboxer on ~sircmpwn/hub.sr.ht

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

#82 Submit builds jobs for patches targeting a specific branch 2 months ago

Ticket created by ~earboxer on ~sircmpwn/hub.sr.ht

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