You are not logged in.
For some of the packages I maintain in the AUR, the PKGBUILDS are stored inside repositories that have histories containing commits without a PKGBUILD or .SRCINFO. This is particularly true for upstream packages that ship with an official PKGBUILD. Trying to push such a project to the AUR fails with an error like:
$ git push aur master
Counting objects: 76, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (34/34), done.
Writing objects: 100% (76/76), 9.98 KiB | 0 bytes/s, done.
Total 76 (delta 42), reused 72 (delta 41)
remote: error: The following error occurred when parsing commit
remote: error: <some-ref-id>:
remote: error: missing .SRCINFO
remote: error: hook declined to update refs/heads/master
To ssh://aur@aur4.archlinux.org/XXX.git
! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'ssh://aur@aur4.archlinux.org/XXX.git'Where
<some-ref-id>is the most recent commit that does not contain a .SRCINFO file.
What is the recommended way to deal with this problem? It is unfeasible to rewrite the entire version history of the project to have them all include PKGBUILD/.SRCINFO, and presumably the AUR doesn't want to have to mirror the entire repositories of upstream projects either.. Are we forced to maintain a separate repository for the PKGBUILDs for each project, and manually keep them in sync with upstream?
Offline
I have run into a similar issue. I've kept my AUR packages in git repos on github for some time now. I assumed I could just add AUR4 as a remote and push to it, but some (many) of my early commits don't have the .SRCINFO file. Would it be possible to have the git hook check HEAD for .SRCINFO rather than every commit?
Offline
git filter-branch --tree-filter will easily add a .SRCINFO to all commits.
As for projects with an upstream PKGBUILD, sounds like a job for git submodules.
Offline
Does AUR4 support git submodules? Does it check them out automatically? Can I symlink into a submodule and expect it to work?
Adding a .SRCINFO is straightforward by rewriting history, yes, but a) that's generally frowned upon, and b) it assumes that *every* commit contains a PKGBUILD. What if the PKGBUILD wasn't added until the second commit for example?
Offline
Does AUR4 support git submodules? Does it check them out automatically? Can I symlink into a submodule and expect it to work?
I think it should be the other way around. Use the AUR repo as a submodule in your project repository.
If you cannot change the source repository, then create a new repository for the aur, add your "official" repository as a secodary remote and update the PKGBUILD with e.g.
git remote add -t master official https://github.com/...
git fetch official master
git checkout --patch official/master PKGBUILD| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
That doesn't seem good either, given that AUR repositories aren't readable unless you have an SSH key registered (might even require you to be the owner, but I don't know that). Are there any plans to expose read-only versions of the AUR package repositories without requiring registered keys?
Offline
That doesn't seem good either, given that AUR repositories aren't readable unless you have an SSH key registered (might even require you to be the owner, but I don't know that). Are there any plans to expose read-only versions of the AUR package repositories without requiring registered keys?
The https url should work I think: https://aur4.archlinux.org/PKGBASE.git/
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
Ah, yes, you're right. Thanks!
I still think it's unfortunate that you either need to modify the upstream repo or manually keep the PKGBUILDs sync'd, but for my use-cases (I control the upstreams), submoduling works fine.
Offline
Here's another request to check just HEAD for .SRCINFO. I don't want to flush 6 years of history because of this. Plus, it's probably the correct behavior anyway. Imagine tomorrow you add some other requirement to the repository, .PKGINFO or something. The package maintainers probably shouldn't be required to re-write all the history to artificially add a new file.
Offline
I'm new to this .SRCINFO stuff, never seen it before. I've always only dealt with PKGBUILDs when working with AUR.
However, it sounds to me the .SRCINFO, if it is actually automatically generated from the PKGBUILD using some script, wouldn't it be better to have a server-side hook that actually re-creates this file on every push? This way the user does not need to know about this file.
Offline
I'm new to this .SRCINFO stuff, never seen it before. I've always only dealt with PKGBUILDs when working with AUR.
However, it sounds to me the .SRCINFO, if it is actually automatically generated from the PKGBUILD using some script, wouldn't it be better to have a server-side hook that actually re-creates this file on every push? This way the user does not need to know about this file.
The file is meant to prevent the execution of possibly malicious shell code on the AUR server. Better do it in a local pre-commit hook.
Last edited by progandy (2015-06-14 17:12:20)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
V01d,
With aur 3.4.0 released on 28-07-2014 metadata files became mandatory for submission of new/updated aur pacakges.
Aur users don't have to worry about these files, only maintainers of aur packages.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
V01d,
With aur 3.4.0 released on 28-07-2014 metadata files became mandatory for submission of new/updated aur pacakges.
Aur users don't have to worry about these files, only maintainers of aur packages.
Escuseme.
I come again to Arch, but I see this breaking news "Aur git", and I installed some pkgs from aur. Will I have to manually change from Aur to Aur4 with some script? or Only Will I have to change yaourtrc?
Offline
Kik1n,
Welcome to Arch. I am not sure what you are asking, but the change to aur4 should be transparent to normal users. I don't know about your breaking news, nor would I bother with a troublesome package such as yaourt
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
@ewaller
Jeje, I'm wondering if I have to reinstall, uninstall&install my pkgs aur from the new aur4repos, or I'll have no problems with this.
Thanks ![]()
Last edited by kik1n (2015-06-14 06:32:57)
Offline
Currently some pkgs on aur4 can be newer than the same aur package, but after July, 8th 2015, all aur4 packages will be available at the old address. So wait until this date, or newer packages from aur4.
Offline
V01D wrote:I'm new to this .SRCINFO stuff, never seen it before. I've always only dealt with PKGBUILDs when working with AUR.
However, it sounds to me the .SRCINFO, if it is actually automatically generated from the PKGBUILD using some script, wouldn't it be better to have a server-side hook that actually re-creates this file on every push? This way the user does not need to know about this file.The file is meant to preventthe execution possibly malicious shell code on the AUR server. Better do it in a local pre-commit hook.
Maybe some info on how to do this on the Wiki would be useful.
Offline
Maybe some info on how to do this on the Wiki would be useful.
I think you can adapt this example:
http://www.hagenburger.net/BLOG/Using-G … o-CSS.html
Maybe you can also copy the checks from the aur into a local hook, then you get an error durig the commit instead of the push.
https://projects.archlinux.org/aurweb.g … te.py#n205
Last edited by progandy (2015-06-14 17:19:46)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
Oh, Thank you all ![]()
Offline
Currently some pkgs on aur4 can be newer than the same aur package, but after July, 8th 2015, all aur4 packages will be available at the old address.
This is incorrect. The move will be on the 8th of August, not the 8th of July. [1,2]
[1] https://lists.archlinux.org/pipermail/a … 30718.html
[2] https://wiki.archlinux.org/index.php/Ar … tory#AUR_4
Last edited by runical (2015-06-15 08:23:55)
Offline