[aur-general] AUR 1.8.1 - Can No Longer Upload Packages
Prior to AUR 1.8.1 being deployed, I could upload a *.tar.gz containing my PKGBUILD to AUR. Now with AUR 1.8.1, here I am trying to upload an updated PKGBUILD which I have verified does exist within my *.tar.gz - yet the AUR web-interface refuses to acknowledge that my PKGBUILD exists as I get stumped with *"**Error trying to unpack upload - PKGBUILD does not exist." *Does this sound like a possible bug with AUR 1.8.1? I would like to think I have been quite diligent with the whole AUR process, but as I said this little road block has got me stumped with AUR 1.8.1 -- Tony
On Sun, Mar 13, 2011 at 06:47:53PM -0700, Tony C wrote:
Prior to AUR 1.8.1 being deployed, I could upload a *.tar.gz containing my PKGBUILD to AUR. Now with AUR 1.8.1, here I am trying to upload an updated PKGBUILD which I have verified does exist within my *.tar.gz - yet the AUR web-interface refuses to acknowledge that my PKGBUILD exists as I get stumped with *"**Error trying to unpack upload - PKGBUILD does not exist."
*Does this sound like a possible bug with AUR 1.8.1? I would like to think I have been quite diligent with the whole AUR process, but as I said this little road block has got me stumped with AUR 1.8.1 -- Tony
I haven't had any problems posting PKGBUILDs since 1.8.1. There were, however, some new rules added to reject malformed sourceballs. Are you using makepkg --source to build your tarball for upload? dave
On 03/13/2011 06:58 PM, Dave Reisner wrote:
On Sun, Mar 13, 2011 at 06:47:53PM -0700, Tony C wrote:
Prior to AUR 1.8.1 being deployed, I could upload a *.tar.gz containing my PKGBUILD to AUR. Now with AUR 1.8.1, here I am trying to upload an updated PKGBUILD which I have verified does exist within my *.tar.gz - yet the AUR web-interface refuses to acknowledge that my PKGBUILD exists as I get stumped with *"**Error trying to unpack upload - PKGBUILD does not exist."
*Does this sound like a possible bug with AUR 1.8.1? I would like to think I have been quite diligent with the whole AUR process, but as I said this little road block has got me stumped with AUR 1.8.1 -- Tony I haven't had any problems posting PKGBUILDs since 1.8.1. There were, however, some new rules added to reject malformed sourceballs. Are you using makepkg --source to build your tarball for upload?
dave I have tried with 'makepkg --source', and also manually creating my tarball with 'tar cvzf package.tar.gz PKGBUILD' verifying the PKGBUILD exists inside the tarball with 'tar tf' yet AUR still complains with the same error with both attempts. Really strange. -- Tony
On Sun, Mar 13, 2011 at 07:11:47PM -0700, Tony C wrote:
On 03/13/2011 06:58 PM, Dave Reisner wrote:
On Sun, Mar 13, 2011 at 06:47:53PM -0700, Tony C wrote:
Prior to AUR 1.8.1 being deployed, I could upload a *.tar.gz containing my PKGBUILD to AUR. Now with AUR 1.8.1, here I am trying to upload an updated PKGBUILD which I have verified does exist within my *.tar.gz - yet the AUR web-interface refuses to acknowledge that my PKGBUILD exists as I get stumped with *"**Error trying to unpack upload - PKGBUILD does not exist."
*Does this sound like a possible bug with AUR 1.8.1? I would like to think I have been quite diligent with the whole AUR process, but as I said this little road block has got me stumped with AUR 1.8.1 -- Tony I haven't had any problems posting PKGBUILDs since 1.8.1. There were, however, some new rules added to reject malformed sourceballs. Are you using makepkg --source to build your tarball for upload?
dave I have tried with 'makepkg --source', and also manually creating my tarball with 'tar cvzf package.tar.gz PKGBUILD' verifying the PKGBUILD exists inside the tarball with 'tar tf' yet AUR still complains with the same error with both attempts. Really strange. -- Tony
Would be helpful if you could post the problematic PKGBUILD. It may be that the AUR is giving you a bogus error. I just tried uploading a few minutes ago and had no issues. dave
On 03/13/2011 07:16 PM, Dave Reisner wrote:
On 03/13/2011 06:58 PM, Dave Reisner wrote:
On Sun, Mar 13, 2011 at 06:47:53PM -0700, Tony C wrote:
Prior to AUR 1.8.1 being deployed, I could upload a *.tar.gz containing my PKGBUILD to AUR. Now with AUR 1.8.1, here I am trying to upload an updated PKGBUILD which I have verified does exist within my *.tar.gz - yet the AUR web-interface refuses to acknowledge that my PKGBUILD exists as I get stumped with *"**Error trying to unpack upload - PKGBUILD does not exist."
*Does this sound like a possible bug with AUR 1.8.1? I would like to think I have been quite diligent with the whole AUR process, but as I said this little road block has got me stumped with AUR 1.8.1 -- Tony I haven't had any problems posting PKGBUILDs since 1.8.1. There were, however, some new rules added to reject malformed sourceballs. Are you using makepkg --source to build your tarball for upload?
dave I have tried with 'makepkg --source', and also manually creating my tarball with 'tar cvzf package.tar.gz PKGBUILD' verifying the PKGBUILD exists inside the tarball with 'tar tf' yet AUR still complains with the same error with both attempts. Really strange. -- Tony Would be helpful if you could post the problematic PKGBUILD. It may be
On Sun, Mar 13, 2011 at 07:11:47PM -0700, Tony C wrote: that the AUR is giving you a bogus error. I just tried uploading a few minutes ago and had no issues.
dave
Here is the build. I really do not see any reason why the build is being rejected, I would have to agree that this is a bogus error. -- Tony
Could the reason be some syntax errors? There are a lot of quotation marks too much. And the settings of your quotation marks seem to be quite inconsistent.
build() { cd "${srcdir}/$pkgname-$pkgver" Better: cd ${srcdir}/$pkgname-$pkgver
package() { cd "${srcdir}/$pkgname-$pkgver" Better: cd ${srcdir}/$pkgname-$pkgver
make prefix="${pkgdir}"/usr install Better: make prefix=${pkgdir}/usr install
install -D -d -m755 "${pkgdir}"/usr/share Better: install -D -d -m755 ${pkgdir}/usr/share
install -D -m644 "${srcdir}/$pkgname-$pkgver"/COPYING \ "${pkgdir}"/usr/share/licenses/"${pkgname}"/LICENSE Better: install -D -m644 ${srcdir}/$pkgname-$pkgver/COPYING ${pkgdir}/usr/share/licenses/$pkgname/LICENSE
Heiko
On Mon, Mar 14, 2011 at 03:32:48AM +0100, Heiko Baums wrote:
Could the reason be some syntax errors? There are a lot of quotation marks too much. And the settings of your quotation marks seem to be quite inconsistent.
build() { cd "${srcdir}/$pkgname-$pkgver" Better: cd ${srcdir}/$pkgname-$pkgver
package() { cd "${srcdir}/$pkgname-$pkgver" Better: cd ${srcdir}/$pkgname-$pkgver
make prefix="${pkgdir}"/usr install Better: make prefix=${pkgdir}/usr install
install -D -d -m755 "${pkgdir}"/usr/share Better: install -D -d -m755 ${pkgdir}/usr/share
install -D -m644 "${srcdir}/$pkgname-$pkgver"/COPYING \ "${pkgdir}"/usr/share/licenses/"${pkgname}"/LICENSE Better: install -D -m644 ${srcdir}/$pkgname-$pkgver/COPYING ${pkgdir}/usr/share/licenses/$pkgname/LICENSE
Heiko
s/Better/Worse/ Inconsistant quoting is better than not quoting at all. If someone's $srcdir expand with a space in it, the build breaks. dave
On 03/13/2011 07:37 PM, Dave Reisner wrote:
On Mon, Mar 14, 2011 at 03:32:48AM +0100, Heiko Baums wrote:
Could the reason be some syntax errors? There are a lot of quotation marks too much. And the settings of your quotation marks seem to be quite inconsistent.
build() { cd "${srcdir}/$pkgname-$pkgver" Better: cd ${srcdir}/$pkgname-$pkgver
package() { cd "${srcdir}/$pkgname-$pkgver" Better: cd ${srcdir}/$pkgname-$pkgver
make prefix="${pkgdir}"/usr install Better: make prefix=${pkgdir}/usr install
install -D -d -m755 "${pkgdir}"/usr/share Better: install -D -d -m755 ${pkgdir}/usr/share
install -D -m644 "${srcdir}/$pkgname-$pkgver"/COPYING \ "${pkgdir}"/usr/share/licenses/"${pkgname}"/LICENSE Better: install -D -m644 ${srcdir}/$pkgname-$pkgver/COPYING ${pkgdir}/usr/share/licenses/$pkgname/LICENSE
Heiko s/Better/Worse/
Inconsistant quoting is better than not quoting at all. If someone's $srcdir expand with a space in it, the build breaks.
dave
Unfortunately it makes no difference even without quoting. -- Tony
Am Sun, 13 Mar 2011 22:37:06 -0400 schrieb Dave Reisner <d@falconindy.com>:
s/Better/Worse/
Inconsistant quoting is better than not quoting at all. If someone's $srcdir expand with a space in it, the build breaks.
He should try it, because double quoting can bring some problems. ${variable} is almost the same as "$variable". Heiko
On Mon, Mar 14, 2011 at 03:46:18AM +0100, Heiko Baums wrote:
Am Sun, 13 Mar 2011 22:37:06 -0400 schrieb Dave Reisner <d@falconindy.com>:
s/Better/Worse/
Inconsistant quoting is better than not quoting at all. If someone's $srcdir expand with a space in it, the build breaks.
He should try it, because double quoting can bring some problems. ${variable} is almost the same as "$variable".
Heiko
Absolutely not. ${var} is identical to $var in every way except one: $varfoo != ${var}foo The curly braces otherwise provide zero differentiation in expansion rules when used in this fashion. dave
Am Sun, 13 Mar 2011 22:58:21 -0400 schrieb Dave Reisner <d@falconindy.com>:
Absolutely not. ${var} is identical to $var in every way except one:
$varfoo != ${var}foo
The curly braces otherwise provide zero differentiation in expansion rules when used in this fashion.
You're wrong again. ${variable} is the same as "$variable". From `man bash`: ${parameter} The value of parameter is substituted. The braces are required when parameter is a positional parameter with more than one digit, or when parameter is followed by a character which is not to be interpreted as part of its name. Heiko
On Mon, Mar 14, 2011 at 04:03:45AM +0100, Heiko Baums wrote:
Am Sun, 13 Mar 2011 22:58:21 -0400 schrieb Dave Reisner <d@falconindy.com>:
Absolutely not. ${var} is identical to $var in every way except one:
$varfoo != ${var}foo
The curly braces otherwise provide zero differentiation in expansion rules when used in this fashion.
You're wrong again. ${variable} is the same as "$variable".
From `man bash`: ${parameter} The value of parameter is substituted. The braces are required when parameter is a positional parameter with more than one digit, or when parameter is followed by a character which is not to be interpreted as part of its name.
Heiko
I don't see how that absolves you from word splitting during expansion. Rather, it enforces the point I made about $varfoo versus ${var}foo. Since / is not a valid character in a variable name, the var name ends before it. How about you do a simple test? $ var="foo bar" $ touch ${var} How many files were created? Remember this is bash, not ZSH. dave
Am Sun, 13 Mar 2011 23:08:06 -0400 schrieb Dave Reisner <d@falconindy.com>:
I don't see how that absolves you from word splitting during expansion. Rather, it enforces the point I made about $varfoo versus ${var}foo. Since / is not a valid character in a variable name, the var name ends before it. How about you do a simple test?
$ var="foo bar" $ touch ${var}
How many files were created? Remember this is bash, not ZSH.
I thought I have tested this already in a PKGBUILD. Maybe I had false memories. Nevertheless I'd suggest removing the quotation marks. If this is not the reason he can add them again. Heiko
On 14 March 2011 10:32, Heiko Baums <lists@baums-on-web.de> wrote:
Could the reason be some syntax errors? There are a lot of quotation marks too much. And the settings of your quotation marks seem to be quite inconsistent.
It would be funny if the AUR rejected PKGBUILDs due to syntax "errors" or inconsistency [1], especially this one where curly braces and double quotes merely dictate whether the build succeeds - not whether it is a valid PKGBUILD. On 14 March 2011 11:44, Tony C <crt.011@gmail.com> wrote:
Apologies for the noise. AUR does not reject my package now after first creating the directory name for the package I have. I do not ever remember needing to create a special directory before. So I simply did mkdir package-name and tar'd that up containing my source files.
That does not tally with what you confirmed with us earlier - that you had tried 'makepkg --source'. [1] http://mailman.archlinux.org/pipermail/arch-general/2010-February/011272.htm...
Am Mon, 14 Mar 2011 11:59:38 +0800 schrieb Ray Rashif <schiv@archlinux.org>:
On 14 March 2011 10:32, Heiko Baums <lists@baums-on-web.de> wrote:
Could the reason be some syntax errors? There are a lot of quotation marks too much. And the settings of your quotation marks seem to be quite inconsistent.
It would be funny if the AUR rejected PKGBUILDs due to syntax "errors" or inconsistency [1], especially this one where curly braces and double quotes merely dictate whether the build succeeds - not whether it is a valid PKGBUILD.
PKGBUILDs shouldn't be rejected due to syntax errors, but you never know, anything can happen. Heiko
On Mon 14 Mar 2011 05:08 +0100, Heiko Baums wrote:
Am Mon, 14 Mar 2011 11:59:38 +0800 schrieb Ray Rashif <schiv@archlinux.org>:
On 14 March 2011 10:32, Heiko Baums <lists@baums-on-web.de> wrote:
Could the reason be some syntax errors? There are a lot of quotation marks too much. And the settings of your quotation marks seem to be quite inconsistent.
It would be funny if the AUR rejected PKGBUILDs due to syntax "errors" or inconsistency [1], especially this one where curly braces and double quotes merely dictate whether the build succeeds - not whether it is a valid PKGBUILD.
PKGBUILDs shouldn't be rejected due to syntax errors, but you never know, anything can happen.
Submitting PKGBUILDs to the AUR isn't exactly a magical happenstance. If you look at the code you will discover that are certain things that happen, and certain things that don't. I realise you're trying to help, but let's please avoid sending people on wild goose hunts. Thanks.
2011/3/14 Ray Rashif <schiv@archlinux.org>
On 14 March 2011 11:44, Tony C <crt.011@gmail.com> wrote:
Apologies for the noise. AUR does not reject my package now after first creating the directory name for the package I have. I do not ever remember needing to create a special directory before. So I simply did mkdir package-name and tar'd that up containing my source files.
That does not tally with what you confirmed with us earlier - that you had tried 'makepkg --source'.
I wonder why one would want to run 'mkdir <pkgname>' and then 'tar cvzf package.tar.gz' when makepkg already have the '--source' feature to do it. Tony C, are you sure you ran 'makepkg --source' and had the same issue as 'tar cvzf package.tar.gz'? - Rafael
Am Sun, 13 Mar 2011 19:20:04 -0700 schrieb Tony C <crt.011@gmail.com>:
pkgname=lft pkgver=3.31 pkgrel=1 pkgdesc="A layer four traceroute implementing numerous other features" arch=('i686' 'x86_64') license=('custom') url="http://oppleman.com/lft/"
The new url is: http://pwhois.org/lft/
depends=('glibc' 'libpcap>=1.0.0')
And you should remove the versioned dependency in AUR. This can have bad effects for the users if the system gets updated by pacman -Syu or yaourt -Syua or the like. Arch Linux is a rolling release distro which has only one version of a package in the repos and you can assume that people keep their systems up-to-date. I don't know if there's a reason for those versioned dependencies for the devs and TUs in the binary repos but in AUR they are usually not necessary and useful. Glibc can also be removed from depends, because it's already in the base group. Heiko
On 03/13/2011 07:44 PM, Heiko Baums wrote:
Am Sun, 13 Mar 2011 19:20:04 -0700 schrieb Tony C <crt.011@gmail.com>:
pkgname=lft pkgver=3.31 pkgrel=1 pkgdesc="A layer four traceroute implementing numerous other features" arch=('i686' 'x86_64') license=('custom') url="http://oppleman.com/lft/" The new url is: http://pwhois.org/lft/
Changed. Note: old URL will redirect to new URL.
depends=('glibc' 'libpcap>=1.0.0') glibc removed and removed version from libpcap.
And you should remove the versioned dependency in AUR. This can have bad effects for the users if the system gets updated by pacman -Syu or yaourt -Syua or the like.
Arch Linux is a rolling release distro which has only one version of a package in the repos and you can assume that people keep their systems up-to-date.
I don't know if there's a reason for those versioned dependencies for the devs and TUs in the binary repos but in AUR they are usually not necessary and useful.
Glibc can also be removed from depends, because it's already in the base group.
Heiko Thanks for the info. Though the bogus error still exists even with these small changes. -- Tony
On Mon 14 Mar 2011 03:44 +0100, Heiko Baums wrote:
Am Sun, 13 Mar 2011 19:20:04 -0700 schrieb Tony C <crt.011@gmail.com>:
pkgname=lft pkgver=3.31 pkgrel=1 pkgdesc="A layer four traceroute implementing numerous other features" arch=('i686' 'x86_64') license=('custom') url="http://oppleman.com/lft/"
The new url is: http://pwhois.org/lft/
depends=('glibc' 'libpcap>=1.0.0')
And you should remove the versioned dependency in AUR. This can have bad effects for the users if the system gets updated by pacman -Syu or yaourt -Syua or the like.
Arch Linux is a rolling release distro which has only one version of a package in the repos and you can assume that people keep their systems up-to-date.
I don't know if there's a reason for those versioned dependencies for the devs and TUs in the binary repos but in AUR they are usually not necessary and useful.
Glibc can also be removed from depends, because it's already in the base group.
What does any of that have to do with a problem uploading the package?
Am Sun, 13 Mar 2011 23:18:34 -0400 schrieb Loui Chang <louipc.ist@gmail.com>:
What does any of that have to do with a problem uploading the package?
Nothing, but if I read the PKGBUILD and I notice it I mention it, too. What's the problem? Heiko
I just confirmed with another user and they too are receiving the same bogus error when trying to upload to AUR, so it appears it is not just me experiencing this issue. -- Tony
Apologies for the noise. AUR does not reject my package now after first creating the directory name for the package I have. I do not ever remember needing to create a special directory before. So I simply did mkdir package-name and tar'd that up containing my source files. -- Tony
On Sun 13 Mar 2011 20:44 -0700, Tony C wrote:
Apologies for the noise. AUR does not reject my package now after first creating the directory name for the package I have. I do not ever remember needing to create a special directory before. So I simply did mkdir package-name and tar'd that up containing my source files.
You need to follow the format created by makepkg --source.
On Sun, Mar 13, 2011 at 11:58:04PM -0400, Loui Chang wrote:
On Sun 13 Mar 2011 20:44 -0700, Tony C wrote:
Apologies for the noise. AUR does not reject my package now after first creating the directory name for the package I have. I do not ever remember needing to create a special directory before. So I simply did mkdir package-name and tar'd that up containing my source files.
You need to follow the format created by makepkg --source.
Yeah, this check was introduced in commit ec0dfc27 [1], so it probably should have occured with 1.8.0 as well. The weird thing is that he actually created a package with `makepkg --source` which was rejected as well. Shouldn't `makepkg --source` always tar(1) up the directory? I'd also like to say that I really appreciate everybody's help but if anyone would have glanced through the AUR package submission source code (and it literally takes 3 minutes) [2], you would have noticed that the contents of the PKGBUILD don't matter at all - the error occurs way before it is even extracted. Don't get me wrong, I know that you all just wanted to help and I don't want to accuse anyone, but this would have been solved way faster (wasting less of your time, also) if anybody would have checked that on a systematic basis instead of guessing repeatedly. [1] http://projects.archlinux.org/aur.git/commit/?id=ec0dfc27 [2] http://projects.archlinux.org/aur.git/tree/web/html/pkgsubmit.php?id=ec0dfc2...
On 14/03/11 12:20, Tony C wrote:
On 03/13/2011 07:16 PM, Dave Reisner wrote:
On 03/13/2011 06:58 PM, Dave Reisner wrote:
On Sun, Mar 13, 2011 at 06:47:53PM -0700, Tony C wrote:
Prior to AUR 1.8.1 being deployed, I could upload a *.tar.gz containing my PKGBUILD to AUR. Now with AUR 1.8.1, here I am trying to upload an updated PKGBUILD which I have verified does exist within my *.tar.gz - yet the AUR web-interface refuses to acknowledge that my PKGBUILD exists as I get stumped with *"**Error trying to unpack upload - PKGBUILD does not exist."
*Does this sound like a possible bug with AUR 1.8.1? I would like to think I have been quite diligent with the whole AUR process, but as I said this little road block has got me stumped with AUR 1.8.1 -- Tony I haven't had any problems posting PKGBUILDs since 1.8.1. There were, however, some new rules added to reject malformed sourceballs. Are you using makepkg --source to build your tarball for upload?
dave I have tried with 'makepkg --source', and also manually creating my tarball with 'tar cvzf package.tar.gz PKGBUILD' verifying the PKGBUILD exists inside the tarball with 'tar tf' yet AUR still complains with the same error with both attempts. Really strange. -- Tony Would be helpful if you could post the problematic PKGBUILD. It may be
On Sun, Mar 13, 2011 at 07:11:47PM -0700, Tony C wrote: that the AUR is giving you a bogus error. I just tried uploading a few minutes ago and had no issues.
dave
Here is the build. I really do not see any reason why the build is being rejected, I would have to agree that this is a bogus error.
I can not see why this is being rejected... Not to sound condescending... but you are uploading the source package (.src.tar.gz) and not the binary (.pkg.tar.xz)? Brain failure happen to us all at times! :D Allan
On 03/13/2011 08:22 PM, Allan McRae wrote:
On 14/03/11 12:20, Tony C wrote:
On 03/13/2011 07:16 PM, Dave Reisner wrote:
On 03/13/2011 06:58 PM, Dave Reisner wrote:
On Sun, Mar 13, 2011 at 06:47:53PM -0700, Tony C wrote:
Prior to AUR 1.8.1 being deployed, I could upload a *.tar.gz containing my PKGBUILD to AUR. Now with AUR 1.8.1, here I am trying to upload an updated PKGBUILD which I have verified does exist within my *.tar.gz - yet the AUR web-interface refuses to acknowledge that my PKGBUILD exists as I get stumped with *"**Error trying to unpack upload - PKGBUILD does not exist."
*Does this sound like a possible bug with AUR 1.8.1? I would like to think I have been quite diligent with the whole AUR process, but as I said this little road block has got me stumped with AUR 1.8.1 -- Tony I haven't had any problems posting PKGBUILDs since 1.8.1. There were, however, some new rules added to reject malformed sourceballs. Are you using makepkg --source to build your tarball for upload?
dave I have tried with 'makepkg --source', and also manually creating my tarball with 'tar cvzf package.tar.gz PKGBUILD' verifying the PKGBUILD exists inside the tarball with 'tar tf' yet AUR still complains with the same error with both attempts. Really strange. -- Tony Would be helpful if you could post the problematic PKGBUILD. It may be
On Sun, Mar 13, 2011 at 07:11:47PM -0700, Tony C wrote: that the AUR is giving you a bogus error. I just tried uploading a few minutes ago and had no issues.
dave
Here is the build. I really do not see any reason why the build is being rejected, I would have to agree that this is a bogus error.
I can not see why this is being rejected...
Not to sound condescending... but you are uploading the source package (.src.tar.gz) and not the binary (.pkg.tar.xz)? Brain failure happen to us all at times! :D
Allan Indeed I am uploading the source package containing all necessary files (i.e PKGBUILD, patches, etc) and not the .pkg.tar.xz binary, which is why I am scratching my head with this. :)
-- Tony
On 3/14/11, Tony C <crt.011@gmail.com> wrote:
Here is the build. I really do not see any reason why the build is being rejected, I would have to agree that this is a bogus error.
-- Tony
I tried test uploading this by changing the pkgname, replacing with one of my packages that nobody uses anyway - and it worked. So what comes to mind is that either the pkgname of yours is too short for AUR 1.8.x (3 letters) or there's something wrong with the tarball itself. Could you upload the tarball somewhere for others to review? Det
On Mon, Mar 14, 2011 at 04:16:49PM +0200, Det wrote:
On 3/14/11, Tony C <crt.011@gmail.com> wrote:
Here is the build. I really do not see any reason why the build is being rejected, I would have to agree that this is a bogus error.
-- Tony
I tried test uploading this by changing the pkgname, replacing with one of my packages that nobody uses anyway - and it worked.
So what comes to mind is that either the pkgname of yours is too short for AUR 1.8.x (3 letters) or there's something wrong with the tarball itself. Could you upload the tarball somewhere for others to review?
This already has been resolved some hours ago, please read the whole thread before replying.
On 03/13/2011 06:47 PM, Tony C wrote:
Prior to AUR 1.8.1 being deployed, I could upload a *.tar.gz containing my PKGBUILD to AUR. Now with AUR 1.8.1, here I am trying to upload an updated PKGBUILD which I have verified does exist within my *.tar.gz - yet the AUR web-interface refuses to acknowledge that my PKGBUILD exists as I get stumped with *"**Error trying to unpack upload - PKGBUILD does not exist."
*Does this sound like a possible bug with AUR 1.8.1? I would like to think I have been quite diligent with the whole AUR process, but as I said this little road block has got me stumped with AUR 1.8.1 -- Tony I tried uploading a different package just to test with the necessary PKGBUILD, patches, and .install file using 'tar czf some-package.tar.gz *' which of course included all the necessary files. Tarball is indeed valid, upload, same bogus error on this different package. Maybe I am cursed.
-- Tony
On Sun 13 Mar 2011 20:19 -0700, Tony C wrote:
On 03/13/2011 06:47 PM, Tony C wrote:
Prior to AUR 1.8.1 being deployed, I could upload a *.tar.gz containing my PKGBUILD to AUR. Now with AUR 1.8.1, here I am trying to upload an updated PKGBUILD which I have verified does exist within my *.tar.gz - yet the AUR web-interface refuses to acknowledge that my PKGBUILD exists as I get stumped with *"**Error trying to unpack upload - PKGBUILD does not exist."
*Does this sound like a possible bug with AUR 1.8.1? I would like to think I have been quite diligent with the whole AUR process, but as I said this little road block has got me stumped with AUR 1.8.1
I tried uploading a different package just to test with the necessary PKGBUILD, patches, and .install file using 'tar czf some-package.tar.gz *' which of course included all the necessary files. Tarball is indeed valid, upload, same bogus error on this different package. Maybe I am cursed.
Tony, can you open a new bug ticket and attach both source packages? Thanks a lot.
participants (9)
-
Allan McRae
-
Dave Reisner
-
Det
-
Heiko Baums
-
Loui Chang
-
Lukas Fleischer
-
rafael ff1
-
Ray Rashif
-
Tony C