• Another test of the Logs functionality. A small x should give us Unix timestamps. You can check the current timestamp.
    • And this. This is the note that will go forth and timestamp appropriately in the Logs directory.
    • A final note. To bid farewell. At night. When it is late. And the timestamps are flowing into a git repo.
  • I’m spending some time working on Moa Party today.
    • I created a new Mastodon account for the project to complete the setup of all of the social accounts for the project. We were thinking that we might run our own Mastodon server at some point, but accounts can be moved pretty easily within Mastodon, so I went ahead and chose the Fosstodon server to create an account on.
    • From the Fosstodon about page, “a community of like-minded people who enjoy Free & Open Source Software (FOSS)”, plus they have a sustainability model of passing donations on to other open source projects after costs are covered.
    • You can follow Moa Party at @[email protected].
  • Git Bug
    • I get excited when I have a chance to try new software and…it just works!1 That was the case with git-bug. It’s a bug tracker that is fully embedded in git. You use the same git repo that you are using for code development to track and update bugs and issues.
    • On MacOS, brew install git-bug and you’re up and running.
    • git bug user create will setup your local user. It will read from your local git settings for full name and email address. The only other thing you’ll need is a full link to an avatar image — the picture that represents you.
    • Next up is setting up bridges. git-bug supports GitLab, GitHub, JIRA, and minor support for Launchpad, as well as custom implementations.
    • The Moa Party project is what I’m going to experiment using git-bug on, which we host on GitLab. You run git bug bridge configure and walk through a terminal interface to fill out your GitLab server details (yes, you can use it with self-hosted GitLab instances), as well as your personal login and an access token.
    • When you create a personal access token, you’ll need to give it api access permission, which pretty much can do everything on your behalf. I initially created a token without that access, and had a heck of a time figuring out how to fix that. Turns out, go into your local ~/.gitconfig and delete the token and identity with the wrong permissions. And, git-bug bridge rm the original bridge you created with the wrong token, then you can git-bug bridge configure a new default.
    • And now, unfortunately, I nuked identities using the Makefile (and found @agentofuser in the issues from a couple of years ago) and am currently in a state where I can’t create a new identity.
    • OK, I got it working through the age old trick of … downloading a new copy of the repo and setting it up again.
    • There is a recent (7 days ago) issue thread that seems to indicate the GitLab API has been improved and this can be working again. git-bug itself works, and I managed to import the existing GitLab issues, but I can’t push changes to the GitLab issues.
    • Since the Agora itself works with git a lot, we may actually be able to link git-bugs with the Agora itself in some way, but that’s pretty deep git magic for me, since I don’t fully understand how git-bug works / where it stores stuff in git.
  • IDGAF Takeout Roulette

    • Can’t decide what to eat and you just don’t give a…? We’ll place a $20 takeout order and have it delivered to you!

    • Seen via @IanColdWater

Footnotes

  1. Of course, further down in this note, after a bunch of git surgery, things did not just work! But you can see the screenshots of things working in the git-bug page. ↩