[autogit] Auto build, update, install PKGBUILD's from Github, Gitlab and AUR via "makepkg", "devtools", "chrootbuild"

Updated - 2024-06-07T10:00:00Z


Autogit is a Bash tool to automatically build, update or install Pacman applications from PKGBUILD’s available on Github, Gitlab and AUR via configurable makepkg, devtools, or Manjaro chrootbuild commands. It can also create automatically repo names like core, extra, community and create/update a repo database file via repo-add. Additionally it clears each local repo with paccache to only keep the latest package version.

Basically if you want to avoid a “git clone” and the rest of the procedure each time a PKGBUILD has been updated and trust the source, then this tool might be for you. Here are some examples:

  • Auto create your own local repositories, add them to /etc/pacman.conf and update with Pacman.
  • Compile packages from different sources into one repository while building all in a clean “chroot”, e.g. AUR, Gitlab, Github.
  • Compile the same package from different branches into different repositories, or add a “-git” PKGBUILD for development on a different branch etc.
  • Use “makepkg” to directly install packages after compilation.

Two different options are available to compare and update applications. In case of a “-git” package it checks for the latest commit to update and can either run once or in a loop with a timer setting.

More information on how to set it up is available in autogit.conf, examples are included.

Currently the AUR, 6 Github and 6 Gitlab sources are available to use. There is no limitation of packages for each source, which need to be added to the reponames folder source files.

In sum 13 different repos can be enabled/created and will be updated together.

How to install:

This package is available on Manjaro and the AUR.

From source:

  • sudo pacman -Syu base-devel git
  • git clone https://github.com/puxplaying/autogit.git
  • cd autogit
  • makepkg -srci

How to run:

  • Run autogit after installation to create a local configuration
  • autogit -h (Help Page and fzf-UI options to manage packages)
Welcome to Autogit's Help Page!

Autogit runs by default without flags.
In order to run autogit, edit the options in

The provided flags will run a fzf UI to manage packages.

autogit [options]:

-e, --edit        - [EDIT]
                    Edit Package List Entries (Commenting With '#' Is Supported)
                    NOTE: Make Sure That The (EDITOR) Environment Variable Is Set On Your System!

-d, --dryrun      - [DRY RUN]
                    Dry Run To Remove Packages - (Nothing Will Be Touched)

-b, --build       - [REBUILD PACKAGES]
                    Remove Package Source(s), Binary(s) And Rebuild The Packge(s)

-r, --remove      - [REMOVE PACKAGES]
                    Remove Package Source(s), Binary(s), Package List Entry(s),
                    Old Database Files And Run "repo-add" If Enabled

-h, --help        - This Help Text

To run it automatically without a password prompt for chrootbuild, it can be added to sudoers via:

echo "$USER ALL = NOPASSWD: /usr/bin/chrootbuild" | sudo tee /etc/sudoers.d/$USER



Nice job, thanks for posting :+1: , something to look at @Manjaro-Team


It looks quite useful.

I would try breaking that code into the smallest functions. It would be the easiest to read and to test.

1 Like

Added check for pkgrel in addition to pkgver to update applications and minor makepkg fixes for all archive types (gz, zst …etc).


Autogit 0.25 was released and is considered to have stable core functionality. I’m currently running it with buildpkg 24/7 on 3 Manjaro Gitlab repos (core, community, extra) with 15 different packages plus my own Github and it seems to do it’s job fine. As always feedback is welcome, happy building! :nerd_face:


I assume you don’t mind this going to the community repo?

Absolutely not, I’m glad if it’s helpful for you guys!
Thanks to @Yochanan i’ve changed some things around buildpkg, so that it now shouldn’t matter for which architecture one is building. As long as it’s set in the right place of the config the binary’s will be moved to the preset repo.
Next step is to implement up to 6 repo’s for Gitlab and Github and add a error handling in case the online source is not available.

Please let me know if there is still something missing or should be implemented!


A new release is out with added check for server availability and support for 6 Gitlab repos, which are preset to all available Manjaro repos in the config file and reponames folder.
In theory one could auto-build all manjaro software into separate local repos and repoadd should do the rest. At least in my tests with a added local repository to pacman.conf it works pretty well and the apps get updated through pacman when i run a system update.


Uploaded to unstable

1 Like

0.29 is out with a reworked server-check which should hopefully work reliable.

Updated in unstable.

1 Like

0.30 is out with a fix for the makepkg installation option, support for 6 Github repos and AUR support.
Happy building! :nerd_face:

1 Like

New version is out with a massive cleaning and improvements.

  • removed duplicate code where possible
  • repoadd now only will be triggered for the specific repo when a update or new build has been done - if enabled. This should be much more resource friendly and faster if a lot repos are enabled.
  • the info output was reworked
  • other small changes and fixes

example output:


Ahem… I forgot to ping @Chrysostomus :stuck_out_tongue_winking_eye:


Thanks! Rebuild pending tonight

EDIT: uploaded to unstable. Thanks again!


The New Year release is out with some eye-candy!

  • Improved visual output
  • More Information about the last run
  • Suppressed unwanted “mv” messages when compiling

Happy New Year! :fireworks:

@Chrysostomus, mea culpa forgot to ping you :see_no_evil:

1 Like

Thanks for the feedback, I think your suggestion is the current state right now after implementing all the wanted functionality and a big cleaning.
I still need to improve on my comments, but the code should be in readable state - at least I hope so. :wink:

From my point of view this tool is currently feature complete as it does what it was meant to do.
Still there is one downside, which it can’t handle like a AUR helper would do for example. Building git packages is not really something it is made for, although it can do it. But as it checks for the pkgver and pkgrel it will always rebuild git packages.

Thank you for sharing!

Questions that may help:

  • For avoiding rebuilds, won’t be enough checking the package version of already built packages?

  • Why exactly 2 github and 3 gitlab sources? Why not an arbitrary amount?

  • Which code repeats in different places? What if that code was a single function or variable by itself?

  • In the configuration file, which variables could be automatically inferred or have a default when not explicitly typed?

  • What if the sources where expressed in one line, like in PKGBUILDS?

  • Should be the AUR url be configurable by the user? Furthermore, could the AUR just be treated as any other source?

  • Which comments or instructions are self explained by the code or context, so removing them really has no consequence?

  • Could a function be expressed in 4-8 lines? Would this program code be easier to find if split into different files? Example here.

  • Pro level: Could these sources be built using multiple machines in parallel?

And some inspiration. Have a nice day :+1:

1 Like
  • This case only applies to git packages which have no “normal” versioning. There is currently no way to check the latest online version, as the online PKGBUILD refers to a older version compared to the local one. Checking the latest built package might be an indicator, but won’t solve the problem as it needs to know when a package is out of date. I will think about how to solve that case with the current approach.
  • This is not the current state anymore, right now it supports 6 Gitlab, 6 Github and the AUR source.
  • The repeating code is one single function with variables in itself to allow different parameter for all the different sources.
  • The most things have a default.
  • The Servercheck is by default off and needs to be un-commented for each server, as i have no idea who uses what.
  • the default settings for “buildpkg” and “makepkg” can either be used as they are, or changed to user preference.
  • After that the default build method shoud be set to the preferred one.
  • repo-add is by default off
  • Finally un-comment the first variable of the preferred source(s) and change the binary folder name to own preferences, that should be all for Github and AUR. If you use Gitlab you also should check the URL as it is preset to Manjaro’s Gitlab. The source filenames can also be changed to user preference in the settings, but also need to be renamed in the reponames folder.
  • Basically everything that is in the settings, can be changed for each source.
  • The sources files in the “reponames” folder are interpreted line by line - for each application one line. Expressing them in one line would lead to a whole new complexity in order to read them accurate. Also as this are all independent packages which can have different Github sources etc., it would be hard to keep an overview and to not make mistakes when adding/deleting packages.

Yes and yes :wink:
The AUR can be seen as any other source. The URL itself shouldn’t normally be touched as long as it doesn’t change.

That is currently not possible other than manually splitting sources to different machines, but a nice idea that i will think about.

Thanks for the feedback!

What I do is using the following for generating pkvers. Call me heretic.

Autogit 1.0 is out now as the first stable release.

@Chrysostomus - ping :wink: