On Mon, 2015-06-08 at 18:05 -0500, Eli Schwartz wrote:

I also have a few githooks for auto-generating .SRCINFO, suggesting a commit message, and auto-generating aurballs for the transitional period where we need to support the old and new AUR interfaces. The `aurpublish` script handles creating and pushing packages.

Suggestions are welcome. :)

Especially those git hooks are a really nice idea!

On 9 June 2015 at 07:05, Eli Schwartz wrote:

On Mon, Jun 8, 2015 at 6:33 AM, Chi Hsuan Yen wrote:

...

(Due to my poor English, the subject may not be easy to understand. I'll explain it below.)

Hello AUR users,

First I'm glad to see that AUR now switches to a git-based package system. I'm always interested in what are changed for an AUR package. Before AUR4, such an information is generally not available unless the submitter leaves a comment.

Now I'd like to talk about my scenario. Before AUR4, I maintain a single git repo for all packages. I need to re-upload all my packages now. There are several handy utilities listed at the AUR wiki [1]. Among them, "import-to-aur4" seems suitable for those who use git repos before AUR4. However, import-to-aur4.sh does not meet my need:

1. It's designed for aur-dev rather than aur4. The workflow is slightly different. 2. Looks like it's a one-time script rather than for long-term use. (See the example usage below)

Is there an existing tool that can read individual packages from a single repo and push it to AUR4? A use case can be:

$ vim python-foobar/PKGBUILD $ git commit -a -m "python-foobar: Update to version x.y.z" $ ./push-package-to-aur4.sh python-foobar

push-package-to-aur4.sh reads from local repo, creates the repo remotely if necessary and pushes PKGBUILD, .SRCINFO, and other source files.

Hope my descriptions are clear enough :)

Best regards,

Yen Chi Hsuan

[1] https://wiki.archlinux.org/index.php/Arch_User_Repository

Yes, I've been fiddling around with exactly that.

Check out https://github.com/eli-schwartz/pkgbuilds to see how I've done it -- I decided to use a subtree push to export per-package folders from a master repository to the AUR per-package repositories.

I also have a few githooks for auto-generating .SRCINFO, suggesting a commit message, and auto-generating aurballs for the transitional period where we need to support the old and new AUR interfaces. The `aurpublish` script handles creating and pushing packages.

Suggestions are welcome. :)

-- Eli Schwartz

Thanks for the awesome tool! I've encoutered "missing .SRCINFO in commit xxx" error, while it's another problem. Yen Chi Hsuan

Also, I have a "base" branch [1] with just the tools cherry-picked, if anyone wants they can use that and add their own packages on top. -- Eli Schwartz [1] https://github.com/eli-schwartz/pkgbuilds/tree/base

On Wed, Jun 10, 2015 at 6:35 PM, Marcel Korpel wrote:

Thanks so much for these hooks. However, I'm not able to install them properly (as I think you intended to install them) and they don't work as I expected (but I'm not well-versed in git hooks at all).

I cloned your repository, went to an AUR4 repo and issued

$ ~/eli-schwartz/pkgbuilds/setup.sh hooks

but links in .git/hooks were not created. Perhaps I erred (it's late already), so I just copied all files to the repository and issued

$ ./setup.sh hooks

Now links were created. If I'm not mistaken, I can make a change in PKGBUILD and

$ git add PKGBUILD $ git commit

Now my not-so-favourite editor popped up, asking for a commit message. As you have a prepare-commit-msg hook, a default message should have been created, but nothing is displayed (I expected the default message, that I could change to my liking). When I leave the commit message blank, the commit is aborted.

How do I use these hooks and your setup script? In which directory should I run it? And are you sure that the test .*/PKGBUILD$ is correct? When I issue `git diff --name-only --cached`, I only get `PKGBUILD`, without a slash. (Well, you probably are correct, as you most likely test your hooks ;)

Thanks again.

Best, Marcel

My intent (see the README.md) is that the hooks,setup script, aurpublish are all tracked within the repo, and that the repo is a single master repo-to-rule-them-all. e.g. : [eschwartz@arch ~/git/pkgbuilds]$ ls -p aurpublish fanficfare/ git-extras/ kindletool-git/ pre-commit.hook README.md calibre-installer/ fanficfare-git/ kindletool/ post-commit.hook prepare-commit-msg.hook setup.sh Each folder contains the PKGBUILD/.SRCINFO/other for a package, and each folder is exported to the AUR using the `./aurpublish` script. The way this works is through the git subtree mechanism -- see: http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree... I prefer it this way, since I can keep a single repository mirrored on GitHub, and because my previous attempt using submodules I regard as too bulky. My hooks therefore loop through all folders in the repo, and run mksrcinfo on those. the prepare-commit-msg hook likewise does so. However, if you are interested in my previous submodules method, checkout the branch "submodules-base" in my repo, and take a look. Again, I intended a single repo-to-rule-them-all, but this one is a git repo that streamlines the process of adding and manipulating AUR4 clones as submodule repos -- that *might* be more to some peoples' liking. -- Eli Schwartz

On Wed, Jun 10, 2015 at 7:52 PM, Justin Dray wrote:

How will that work for new packages you take maintainership of? I'm not a git wizard, but taking a look at the stuff I can't see any way it merges in an external git repo in to yours when you take over an existing orphaned package. I tried the submodule thing as well and found it horrible inadequate. I was going to just query the AUR to find my package list and clone down/update all the returned repositories, and just keep the scripts in a repo by itself.

- Justin Dray

You can add a git subtree that already existed elsewhere, and then push to it. :) The disadvantage is that it creates a subtree merge commit (I despise merge commits, they're 99% of the time ugly and meaningless) that you see in the main repo history, and following the previous history can be awkward. See: https://stackoverflow.com/questions/10918244/git-subtree-without-squash-view... That isn't really a tremendously important issue, as I primarily want to ensure people can still host on GitHub for contributions, as well as the one-repo-to-rule-them-all approach just being nicer. But while merge commits are a necessary evil, I wish at least git was smart enough to follow the history.