FS#8672 - Can't submit new package to AUR
Attached to Project:
AUR web interface
Opened by Alexander Drozdov (adrozdov) - Saturday, 17 November 2007, 04:49 GMT
Last edited by Loui Chang (louipc) - Wednesday, 03 September 2008, 22:41 GMT
Opened by Alexander Drozdov (adrozdov) - Saturday, 17 November 2007, 04:49 GMT
Last edited by Loui Chang (louipc) - Wednesday, 03 September 2008, 22:41 GMT
|
Details
Submit new package but it fail: 'can't create direcrory
/home/aur/qca2'
I look to http://aur.archlinux.org/packages/qca2/ but directory is present and my archive is present also but it is not unpacked. |
This task depends upon
This task blocks these from closing
FS#10701 - Cannot upload new package to AUR.
FS#10796 - cannot add package virt-viewer
FS#10859 - encfs is missing
Closed by Loui Chang (louipc)
Wednesday, 03 September 2008, 22:41 GMT
Reason for closing: Duplicate
Additional comments about closing: This is probably a duplicate of FS#11187
11187 has more relevant detail so discussion should continue on that thread.
Wednesday, 03 September 2008, 22:41 GMT
Reason for closing: Duplicate
Additional comments about closing: This is probably a duplicate of
11187 has more relevant detail so discussion should continue on that thread.
Should be working now. Sorry about that.
There should be a src-folder check...
The file i'm trying to upload -
I received this error from aurup bash utility and from aur web client too.
on my local instance of AUR.
What seems to be the problem is that if you upload a package that
depends on another non-existing package it will lock you out from
uploading the dependency.
I think the assumption here was that if you put a dependency and it
didn't exist in AUR that it had to exist in the official repos. That's
a silly assumption of course because things do change.
Gee there are a lot of bugs I've seen caused by too many assumptions.
There might be more to the bug because I have seen some other weird
behaviour, but this is one case I can confirm from a test.
This definitely requires a code patch and possibly some database modification.
A one-off fix would be to modify the relevant database entries to make
the dependency look like a normal AUR package.
thx.
USE AUR;
UPDATE Packages SET DummyPkg = 0 WHERE Name = "pkgname";
UPDATE Packages SET LocationID = 2 WHERE Name = "pkgname";
The package should then be visible as an orphan from the web interface.
Adopt it and upload your tarball.
See http://projects.archlinux.org/?p=aur.git;a=commitdiff;h=a49ee80aa2e03843748e89185fd811d83cd34db9
The only concern for the upgrade would be making sure that the
Pear modules are properly installed and found by pkgsubmit.php.
I hope Simo will take care of it soon.
After update to 1.5.2, it not says "Could not create directory /home/aur/unsupported/zaptel."
The package i'm trying to submit is attached.
As far as I can tell, the only thing similar between this bug and 11187 is the message displayed to the user, and the workaround (delete the directory on AUR filesystem).
Loui, is that correct?
What about the following list :
http://wiki.archlinux.org/index.php/AUR_CleanUp_Day#Remove_from_Filesystem_.28AUR_Bugs.29
How badly outdated is it?
Here is the packet:
I think this bug (8672) and 11187 are actually the same and I just managed
to find a separate bug which was preventing uploads of dependencies.
Removing directories would not have remedied the bug that was solved.
I'll close this and continue the line of investigation via 11187 since there
are more relevant details about the bug there.
I believe that the list of bad directories at
http://wiki.archlinux.org/index.php/AUR_CleanUp_Day is still pretty relevant.
I think we can automate removal of all files of packages that aren't in the
database. Since users can no longer delete packages, so there's no chance of
malicious adoption then deletion of packages.