[aur-general] AUR4 refuses to accept *any* commit that doesn't have a .SRCINFO
I just submitted my first package, so I'm still learning. However, because I forgot to include a .SRCINFO file until the last commit (i.e several commits including the first did not have .SRCINFO), AUR4 refused to accept anything altogether. kyle@landru ~/builds/aur4/wmload :( $ git push -v origin master Pushing to ssh+git://aur@aur4.archlinux.org/wmload.git X11 forwarding request failed on channel 0 Counting objects: 12, done. Delta compression using up to 8 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (12/12), 1.79 KiB | 0 bytes/s, done. Total 12 (delta 2), reused 0 (delta 0) remote: error: The following error occurred when parsing commit remote: error: d495231b82fd541d626b46aafbfba78d5302e53f: remote: error: missing .SRCINFO remote: error: hook declined to update refs/heads/master To ssh+git://aur@aur4.archlinux.org/wmload.git ! [remote rejected] master -> master (hook declined) error: failed to push some refs to 'ssh+git://aur@aur4.archlinux.org/wmload.git' So, now I apparently have to rewrite git history so that *every* commit has .SRCINFO. (Bear in mind I already copied the repo to GitHub, so I have multiple copies to correct.) IMHO, there should be a clear warning on the wiki page about this. I eventually gave up and re-initted the repos. This begs some questions: 1. Is there any way to generate the .SRCINFO file without doing the tar/untar workaround? 2. Why is .SRCINFO even needed? Why can't AUR parse the raw PKGBUILD? --Kyle
On Mon, 25 May 2015 17:19:07 -0700 Kyle Terrien <kyleterrien@gmail.com> wrote:
1. Is there any way to generate the .SRCINFO file without doing the tar/untar workaround?
mksrcinfo from pkgbuild-introspection-git. You can easily use it to add it to all commmits with git filter-branch --tree-filter
2. Why is .SRCINFO even needed? Why can't AUR parse the raw PKGBUILD?
There are no decent bash parsers out there. To get real info, they would have to be sourced/executed, which is a huge security risk.
https://gist.github.com/taylorchu/76bee1ed238cb79cc444 This helps me a lot :) On Mon, May 25, 2015 at 7:15 PM, Doug Newgard <scimmia@archlinux.info> wrote:
On Mon, 25 May 2015 17:19:07 -0700 Kyle Terrien <kyleterrien@gmail.com> wrote:
1. Is there any way to generate the .SRCINFO file without doing the tar/untar workaround?
mksrcinfo from pkgbuild-introspection-git. You can easily use it to add it to all commmits with git filter-branch --tree-filter
2. Why is .SRCINFO even needed? Why can't AUR parse the raw PKGBUILD?
There are no decent bash parsers out there. To get real info, they would have to be sourced/executed, which is a huge security risk.
* Tai-Lin Chu <tailinchu@gmail.com> (Mon, 25 May 2015 19:24:32 -0700):
Looks nice, but I'm not too fond of the idea of creating a default .gitignore that only includes the bare minimum of files: there are many packages that have custom install files, desktop files, etc., and not including them by default will result in issues at the end user side. In general, I'm more in favour of excluding unwanted files over explicit including. For instance, have a look at https://github.com/github/gitignore/blob/master/ArchLinuxPackages.gitignore (of course, you want to include .SRCINFO now). Best, Marcel
According to Doug Newgard: # There are no decent bash parsers out there. To get real info, they would have # to be sourced/executed, which is a huge security risk. In that case, why can PKGBUILD, which is already a bash script, not just source .SRCINFO, which has its fields in roughly the same format? There just has to be a better method of getting all the right information into the right places without duplicating all the metadata. Sent from my golf bag -- "Don't judge my disability until you are able to see my ability." ~Kyle: https://kyle.tk/ My chunk of the internet: https://chunkhost.com/r/Kyle
On Mon, 25 May 2015 23:05:11 -0400 Kyle <kyle@gmx.ca> wrote:
According to Doug Newgard: # There are no decent bash parsers out there. To get real info, they would have # to be sourced/executed, which is a huge security risk.
In that case, why can PKGBUILD, which is already a bash script, not just source .SRCINFO, which has its fields in roughly the same format? There just has to be a better method of getting all the right information into the right places without duplicating all the metadata. Sent from my golf bag
Because the fields are in no way in the same format whatsoever.
I can see that .SRCINFO is completely different from the fields in PKGBUILD after all. It isn't just the spaces left and right of the = sign as I first thought. Apparently it doesn't show arrays in the same way either, instead putting the same key on multiple lines with one value per key. So this isn't exactly as trivial as I thought, although I still think there would have to be a way to keep from having to duplicate metadata, but as long as there is something that can take the info from the PKGBUILD and generate the file, it isn't really a big problem. Sent from the horns of a goat -- "Don't judge my disability until you are able to see my ability." ~Kyle: https://kyle.tk/ My chunk of the internet: https://chunkhost.com/r/Kyle
although I still think there would have to be a way to keep from having to duplicate metadata,
I had similar discussion before. Putting the whole build script in one file is a very simple and convenient design. If we want to ensure safety and don't want to duplicate meta data, splitting PKGBUILD file is required. On Mon, May 25, 2015 at 8:56 PM, Kyle <kyle@gmx.ca> wrote:
I can see that .SRCINFO is completely different from the fields in PKGBUILD after all. It isn't just the spaces left and right of the = sign as I first thought. Apparently it doesn't show arrays in the same way either, instead putting the same key on multiple lines with one value per key. So this isn't exactly as trivial as I thought, although I still think there would have to be a way to keep from having to duplicate metadata, but as long as there is something that can take the info from the PKGBUILD and generate the file, it isn't really a big problem. Sent from the horns of a goat -- "Don't judge my disability until you are able to see my ability." ~Kyle: https://kyle.tk/ My chunk of the internet: https://chunkhost.com/r/Kyle
IMHO, the ability to run complex script to generate metadata in PKGBUILD is important. Consider the pkgver field for most VCS packages (ex. -git ones) that use VCS command with text manipulation tools (sed, awk, etc.) to extract current version from VCS repositories. The corresponding field in the .SRCINFO file is only the execution output of PKGBUILD, but not the duplication of information already in PKGBUILD. In the other hand, running arbitrary commands in user uploaded PKGBUILD on aur server may be insecure. Therefore we have users to run their PKGBUILD on their machines to extract the .SRCINFO and then upload .SRCINFO together with PKGBUILD to the aur server. On Tue, May 26, 2015 at 12:56 PM, Kyle <kyle@gmx.ca> wrote:
I can see that .SRCINFO is completely different from the fields in PKGBUILD after all. It isn't just the spaces left and right of the = sign as I first thought. Apparently it doesn't show arrays in the same way either, instead putting the same key on multiple lines with one value per key. So this isn't exactly as trivial as I thought, although I still think there would have to be a way to keep from having to duplicate metadata, but as long as there is something that can take the info from the PKGBUILD and generate the file, it isn't really a big problem. Sent from the horns of a goat -- "Don't judge my disability until you are able to see my ability." ~Kyle: https://kyle.tk/ My chunk of the internet: https://chunkhost.com/r/Kyle
-- -------------------------------------------------------------------------------- Jiachen Yang 楊嘉晨 Graduate School of Information Science and Technology, Osaka University Tel: 080-3853-2770 MSN: firechildren@hotmail.com GMail: farseerfc@gmail.com
Also will reject mistypos in pkgbase pkgname for the same reason and with the same circuntances even if you hace a .SRCINFO El mar., 26 de may. de 2015 a la(s) 1:50 a. m., Jiachen Yang < farseerfc@gmail.com> escribió:
IMHO, the ability to run complex script to generate metadata in PKGBUILD is important. Consider the pkgver field for most VCS packages (ex. -git ones) that use VCS command with text manipulation tools (sed, awk, etc.) to extract current version from VCS repositories. The corresponding field in the .SRCINFO file is only the execution output of PKGBUILD, but not the duplication of information already in PKGBUILD.
In the other hand, running arbitrary commands in user uploaded PKGBUILD on aur server may be insecure. Therefore we have users to run their PKGBUILD on their machines to extract the .SRCINFO and then upload .SRCINFO together with PKGBUILD to the aur server.
On Tue, May 26, 2015 at 12:56 PM, Kyle <kyle@gmx.ca> wrote:
I can see that .SRCINFO is completely different from the fields in PKGBUILD after all. It isn't just the spaces left and right of the = sign as I first thought. Apparently it doesn't show arrays in the same way either, instead putting the same key on multiple lines with one value per key. So this isn't exactly as trivial as I thought, although I still think there would have to be a way to keep from having to duplicate metadata, but as long as there is something that can take the info from the PKGBUILD and generate the file, it isn't really a big problem. Sent from the horns of a goat -- "Don't judge my disability until you are able to see my ability." ~Kyle: https://kyle.tk/ My chunk of the internet: https://chunkhost.com/r/Kyle
--
-------------------------------------------------------------------------------- Jiachen Yang 楊嘉晨 Graduate School of Information Science and Technology, Osaka University Tel: 080-3853-2770 MSN: firechildren@hotmail.com GMail: farseerfc@gmail.com
On 05/25/2015 07:15 PM, Doug Newgard wrote:
On Mon, 25 May 2015 17:19:07 -0700 Kyle Terrien <kyleterrien@gmail.com> wrote:
1. Is there any way to generate the .SRCINFO file without doing the tar/untar workaround?
mksrcinfo from pkgbuild-introspection-git. You can easily use it to add it to all commmits with git filter-branch --tree-filter
Wow! I didn't know about mksrcinfo, but I'm definitely using it now. And according to the manual, that git filter-branch command actually modifies every commit in the repo. I had no idea you could do that. Git never ceases to amaze me.
2. Why is .SRCINFO even needed? Why can't AUR parse the raw PKGBUILD?
There are no decent bash parsers out there. To get real info, they would have to be sourced/executed, which is a huge security risk.
I wonder if Perl can parse it. I'll have to try a couple of experiments sometime. Thank you so much, --Kyle
On 05/26/2015 05:17 AM, Kyle Terrien wrote:
I wonder if Perl can parse it. I'll have to try a couple of experiments sometime.
Tried that and gave up... I have to dynamically get info from PKGBUILDS in my "repo-make" tool: http://repo-make.tuxfamily.org/ And I finally decided to launch an instance of bash to do the work for me: http://git.tuxfamily.org/repomake/main.git/tree/repo-make#n604
participants (8)
-
Doug Newgard
-
Jiachen Yang
-
Kyle
-
Kyle Terrien
-
Manuel Reimer
-
Marcel Korpel
-
Pablo Lezaeta Reyes
-
Tai-Lin Chu