FS#54758 - optdepends are displayed in red in some AUR packages

Attached to Project: AUR web interface
Opened by Daniel Bermond (Bermond) - Monday, 10 July 2017, 15:08 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 06 November 2017, 16:19 GMT
Task Type Bug Report
Category PKGBUILD Parser
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.4.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Two of my maintained AUR packages are showing optdends in red, like if they were not found anywhere by the AUR system, but the problematic packages do exist.

They are:

1) ffmpeg-git:
- https://aur.archlinux.org/packages/ffmpeg-git/
- has 'ladspa' optional dependency in red, but this package is in [extra]
- note: 'ladspa' is also a make dependency, but strangely it shows normally in makedepends and is displayed in red only in optdepends

2) ffmpeg-full-git:
- https://aur.archlinux.org/packages/ffmpeg-full-git/
- has 'intel-media-sdk' optional dependency in red, but this package is on the AUR

I also maintain other AUR packages with optdepends (with and without the optional description), but this problem seems to be happening only on these two.

As far as I can tell, this was not happening before, although I cannot say when this started.
By reviewing the PKGBUILD I could not find any problem on it, like unmatched quotes or parentheses or any other flaw.
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Monday, 06 November 2017, 16:19 GMT
Reason for closing:  Fixed
Comment by Daniel Bermond (Bermond) - Monday, 10 July 2017, 20:54 GMT
Another AUR package maintainer has reported the same issue: https://aur.archlinux.org/packages/qbittorrent-git/

Something seems to be broken on the AUR interface when parsing optdepends that contains a ':' followed by a description.
This is happening only with packages that received a new push update.
Comment by Eli Schwartz (eschwartz) - Monday, 10 July 2017, 21:09 GMT
Sure did. :) Pushing a package that received a pkgver, source, and pkgver() update was enough to trigger this.

Sometime recently, aurweb seems to have decided to change the way it regenerates metadata from .SRCINFO files...
The description is supposed to be stripped from the pkgname but instead the entire key is being used to list the pkgname.

I'm not even sure how this could happen if no one has touched aurweb.
Comment by Lukas Fleischer (lfleischer) - Tuesday, 11 July 2017, 05:08 GMT
It is not true that nobody touched aurweb. Florian asked me to backport commit 44858e0 (Store dependency descriptions in a separate column, 2017-04-19) [1] to our live setup because of performance issues on the server. I did that a couple of days ago but forgot to run `python setup.py install` to update the Git hooks. Should be fixed now -- could you please confirm?

[1] https://git.archlinux.org/aurweb.git/commit/?id=44858e06188946c0082bb09061fcfa6cbb33938b
Comment by Eli Schwartz (eschwartz) - Tuesday, 11 July 2017, 05:22 GMT
Tested with lastpass-cli-git, works okay. :)

While I have been known to push commits for upstream releases of git packages, I prefer not to add entirely junk commits to qbittorrent-git, is there any way to regenerate it without committing a pkgrel bump or something?
Comment by Lukas Fleischer (lfleischer) - Tuesday, 11 July 2017, 05:33 GMT
Maybe try `ssh aur@aur.archlinux.org restore qbittorrent-git`? Not entirely sure whether that works, though...
Comment by Lukas Fleischer (lfleischer) - Tuesday, 11 July 2017, 05:36 GMT
No, seems like it doesn't; the restore command requires that the package does not exist. Maybe we should have something like a "reparse" command then?
Comment by Eli Schwartz (eschwartz) - Tuesday, 11 July 2017, 05:39 GMT
I don't know. It does seem somewhat overkill to have a dedicated ssh interface for something that should arguably only ever be needed when fixing a buggy production of aurweb.
Comment by Lukas Fleischer (lfleischer) - Tuesday, 11 July 2017, 06:14 GMT
Well, that command would essentially be the same as restore, except it does not try to create the package base. Only few SLOC added. Cannot hurt to have such a "advanced" command, I guess?
Comment by Daniel Bermond (Bermond) - Tuesday, 11 July 2017, 16:27 GMT
I can confirm that it's now fixed after pushing a new commit to ffmpeg-git and ffmpeg-full-git (it would be good to have a ssh command that could do it without the need of a new commit).

Thank you for fixing this!

Loading...