[aur-general] Attempt to upload llvm35 to AUR gets rejected
The llvm35 package recently got kicked from extra, but I need it for my Pure package (https://aur.archlinux.org/packages/pure/) which in turn is needed for a bunch of other packages I maintain in the AUR.
So I resurrected llvm35 from extra, brushed it up a little so that it compiles again (also bumped the package revision), and tried to upload it to the AUR under the previous package name llvm35. All I get is:
Writing objects: 100% (8/8), 4.76 KiB | 2.38 MiB/s, done. Total 8 (delta 1), reused 0 (delta 0) remote: error: package already provided by []: llvm35 remote: error: hook declined to update refs/heads/master To ssh://aur.archlinux.org/llvm35.git ! [remote rejected] master -> master (hook declined) error: failed to push some refs to 'ssh://aur@aur.archlinux.org/llvm35.git'
My version of the PKGBUILD is available here: https://bitbucket.org/agraef/llvm35-pkgbuild
It's a split package, but isn't that supposed to be supported by the AUR? Anything else wrong with it?
Any help appreciated, many thanks in advance. Albert
On 06-04-18 08:11, Albert Graef via aur-general wrote:
The llvm35 package recently got kicked from extra, but I need it for my Pure package (https://aur.archlinux.org/packages/pure/) which in turn is needed for a bunch of other packages I maintain in the AUR.
So I resurrected llvm35 from extra, brushed it up a little so that it compiles again (also bumped the package revision), and tried to upload it to the AUR under the previous package name llvm35. All I get is:
Writing objects: 100% (8/8), 4.76 KiB | 2.38 MiB/s, done. Total 8 (delta 1), reused 0 (delta 0) remote: error: package already provided by []: llvm35 remote: error: hook declined to update refs/heads/master To ssh://aur.archlinux.org/llvm35.git ! [remote rejected] master -> master (hook declined) error: failed to push some refs to 'ssh://aur@aur.archlinux.org/llvm35.git'
My version of the PKGBUILD is available here: https://bitbucket.org/agraef/llvm35-pkgbuild
It's a split package, but isn't that supposed to be supported by the AUR? Anything else wrong with it?
Any help appreciated, many thanks in advance. Albert
Although SRCINFO does have pkgbase=llvm35 in it, that's not in the PKGBUILD. I doubt that's the cause of the issue, but try adding pkgbase explicitly to PKGBUILD.
I think AUR uses a blacklist to prevent duplicates with offical repos, maybe that blacklist needs updating ?
AUR has llvm33 , llvm38, llvm39, llvm4 and llvm 5 . Maybe your packages can use one of those ?
lW
On 04/06/2018 07:12 AM, LoneVVolf wrote:
Although SRCINFO does have pkgbase=llvm35 in it, that's not in the PKGBUILD. I doubt that's the cause of the issue, but try adding pkgbase explicitly to PKGBUILD.
Explicitly contrary to the PKGBUILD spec; if pkgbase is unset, makepkg sets it from the first element of pkgname, and this is why the .SRCINFO still shows it.
I think AUR uses a blacklist to prevent duplicates with offical repos, maybe that blacklist needs updating ?
The blacklist currently contains llvm35, which I think is because it is erroring when running updates.
``` [eschwartz@luna ~]$ ./aurblup.py inserting update for libreoffice-still-pa-in (provides: libreoffice-pa-IN) Traceback (most recent call last): File "./aurblup.py", line 55, in <module> main() File "./aurblup.py", line 44, in main "VALUES (?, ?, ?)", [pkg, repo, provides]) File "/usr/lib/python3.6/site-packages/aurweb-4.6.0-py3.6.egg/aurweb/db.py", line 43, in execute File "/usr/lib/python3.6/site-packages/mysql/connector/cursor.py", line 561, in execute self._handle_result(self._connection.cmd_query(stmt)) File "/usr/lib/python3.6/site-packages/mysql/connector/connection.py", line 514, in cmd_query result = self._handle_result(self._send_cmd(ServerCmd.QUERY, query)) File "/usr/lib/python3.6/site-packages/mysql/connector/connection.py", line 416, in _handle_result raise errors.get_exception(packet) mysql.connector.errors.IntegrityError: 1062 (23000): Duplicate entry 'libreoffice-still-pa-in-libreoffice-pa-IN' for key 'ProviderNameProvides' ```
On Sun, Apr 8, 2018 at 5:56 AM, Eli Schwartz via aur-general aur-general@archlinux.org wrote:
Explicitly contrary to the PKGBUILD spec; if pkgbase is unset, makepkg sets it from the first element of pkgname, and this is why the .SRCINFO still shows it.
I can add an explicit pkgbase=llvm35 again. (I already tried that before and it didn't fix the upload problem, so I removed it again, because that's the way it was in the original PKGBUILD from extra.)
The blacklist currently contains llvm35, which I think is because it is erroring when running updates.
It sure is. Can anyone of the admins remove it, please?
Thanks Albert
On 04/08/2018 03:29 AM, Albert Graef via aur-general wrote:
On Sun, Apr 8, 2018 at 5:56 AM, Eli Schwartz via aur-general aur-general@archlinux.org wrote:
Explicitly contrary to the PKGBUILD spec; if pkgbase is unset, makepkg sets it from the first element of pkgname, and this is why the .SRCINFO still shows it.
I can add an explicit pkgbase=llvm35 again. (I already tried that before and it didn't fix the upload problem, so I removed it again, because that's the way it was in the original PKGBUILD from extra.)
The blacklist currently contains llvm35, which I think is because it is erroring when running updates.
It sure is. Can anyone of the admins remove it, please?
I've removed it manually, we're looking at a more permanent solution.
On Sun, Apr 8, 2018 at 9:40 AM, Eli Schwartz via aur-general aur-general@archlinux.org wrote:
I've removed it manually, we're looking at a more permanent solution.
Thanks, Eli! I'll give it another go immediately.
Albert
On Sun, Apr 8, 2018 at 9:51 AM, Albert Graef aggraef@gmail.com wrote:
Thanks, Eli! I'll give it another go immediately.
Worked, thanks again!
LoneVVolf wrote:
AUR has llvm33 , llvm38, llvm39, llvm4 and llvm 5 . Maybe your packages can use one of those ?
LLVM 3.5 is the last version which still has the old JIT backend, which is what Pure still needs right now. LLVM 3.4 would work just as well, but that's not available in the AUR, and LLVM 3.3 is 2 years older than 3.5, so I'd rather not use it if I can avoid it.
You might ask why I've not updated Pure to the new JIT yet. In fact, that has been on my TODO list for a long time, but I've been busy with other projects, and it's not straightforward because Pure needs the ability to recompile a function on the spot, which the new MCJIT doesn't offer any more, so I'll have to rewrite Pure's entire code generator for the MCJIT.
Albert
participants (3)
-
Albert Graef
-
Eli Schwartz
-
LoneVVolf