Last active 7 days ago


Last active 2 months ago


Last active 1 year, 7 months ago


Last active 2 years ago
View more

Recent activity

ijq v0.4.0 released 7 days ago

From Gregory Anders to ~gpanders/ijq

Version 0.4.0 of ijq has been released.

This is a minor feature release. See the [release notes][1] for a list
of changes.


[1]: https://git.sr.ht/~gpanders/ijq/refs/v0.4.0

[PATCH vomit] fix typo: s/emtpy/empty 14 days ago

From Gregory Anders to ~bitfehler/public-inbox

 README.md                   |  2 +-
 contrib/vmt-completion.bash |  2 +-
 src/att.rs                  | 16 ++++++++--------
 src/cat.rs                  |  4 ++--
 src/mime.rs                 |  4 ++--
 src/pick.rs                 |  6 +++---
 src/show.rs                 |  4 ++--
 7 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/README.md b/README.md
index 5ecba13..77448c8 100644
--- a/README.md
+++ b/README.md
[message trimmed]

Version 0.3.8 released a month ago

From Gregory Anders to ~gpanders/ijq

I forgot to bump the version number in the Makefile for 0.3.7, so
unfortunately that release is a dud. But it's just as well, because
there were two other (small) fixes I was able to squeeze in.

Packagers should please skip 0.3.7 and go straight to 0.3.8. The release
notes for 0.3.8 are listed here:


These should effectively be combined with the release notes for 0.3.7
(listed in the prior email). Apologies for the confusion!

Version 0.3.7 released a month ago

From Gregory Anders to ~gpanders/ijq

Version 0.3.7 of ijq has just been released. This is a minor bugfix

As noted in a previous email on this list, the names of the pre-built
binaries that are automatically built in the build pipeline have

>This is just an FYI that the names of the binary release tarballs
>attached to releases on git.sr.ht will change from using "x86_64" to
>"amd64" beginning with the next release. The build pipeline now creates
>binary releases for Linux and macOS, and because the pipeline now
>builds multiple architectures I am using the terminology that `go
>build` itself uses to simplify things.

[PATCH] Add support for standard readline bindings a month ago

From Gregory Anders to ~delthas/senpai-dev

* Use Ctrl-F and Ctrl-B to move forward/backward one character
* Use Alt-F and Alt-B to move forward/backward one word
* Use Ctrl-A and Ctrl-E to move to the beginning/end of the input line
* Use Ctrl-K to delete all text from the cursor position to the end of
  the current line
 app.go           | 14 ++++++++++++++
 doc/senpai.1.scd | 22 ++++++++++++++++++++++
 ui/editor.go     | 15 +++++++++++++++
 ui/ui.go         |  4 ++++
 4 files changed, 55 insertions(+)

diff --git a/app.go b/app.go
index b044a06..768327f 100644
[message trimmed]

Re: hut fails to upload artifact in build pipeline a month ago

From Gregory Anders to ~sircmpwn/sr.ht-discuss

On Fri, 06 May 2022 12:57 +0200, Drew DeVault wrote:

Thanks, it is working now.

For anyone following along, I ended up needing the following oauth

     oauth: git.sr.ht/OBJECTS:RW git.sr.ht/REPOSITORIES:RO git.sr.ht/PROFILE:RO

hut fails to upload artifact in build pipeline a month ago

From Gregory Anders to ~sircmpwn/sr.ht-discuss

I am trying to use hut to upload a build artifact to a git ref. My build
manifest is here:


The build fails with the error "2022/05/05 17:39:29 no instance for
git.sr.ht found". Here is the link to the build:


I SSH'd into the build to take a look at the hut config file on the
build runner and noticed that it's missing an entry for the "git"

Re: [sr.ht builds] How should $PATH-changing manifests be handled? 2 months ago

From Gregory Anders to ~sircmpwn/sr.ht-discuss

On Wed, 04 May 2022 20:53 +0200, witcher@wiredspace.de wrote:
>I'm trying to build a manifest for a Rust project, using `alpine/edge`.
>To install Rust, it uses `rustup`, which installs `rustup-init` on
>Calling it changes `$PATH` by sourcing environment variables from
>`$HOME/.cargo/env` in `$HOME/.profile`.
>`$HOME/.profile` doesn't seem to be read on running a task, therefore
>making any tools installed by `rustup-init` unavailable, unless
>specified with their full path.
>Does a way around specifying the full path to the executable every time,
>manually or with an environment variable in the build manifest, exist?
>I'd like to avoid this.

Re: Permanent Build Artifacts 2 months ago

From Gregory Anders to ~sircmpwn/sr.ht-discuss

On Tue, 26 Apr 2022 17:42 +0100, Abdul Raji wrote:
>Was just wondering whether saving build artifacts after 90 days is in 
>the pipeline. I noticed that it was mentioned on the March 2020 update 
>blog post, but hasn't been talked about since afaik. Is it being 
>thought about, or is there another way?

As Drew mentioned you can attach build artifacts to git refs using the
API. If you'd like an example, you can see what I've done here [1],
though I can't promise it's any good. A much better and easier way to do
this would be to use the hut CLI tool [2], which if I recall correctly
integrates with the "oauth" field of the build manifest to make this
kind of thing fairly straightforward (I haven't gotten around to redoing

[PATCH v4] paste: allow specifying name when reading from stdin 2 months ago

From Gregory Anders to ~emersion/hut-dev

When creating a paste from stdin the paste's name is hardcoded to "-".
Add a new flag that allows the user to specify a name for the paste only
when reading from stdin. It is an error to use the --name flag when not
reading from stdin.

Updated man page

 doc/hut.1.scd | 3 +++
 paste.go      | 8 +++++++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/doc/hut.1.scd b/doc/hut.1.scd
index 51414bb..988d913 100644
[message trimmed]