Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#26573 - [srcpac] spins around gcc-libs all the time

Attached to Project: Arch Linux
Opened by Andrej Podzimek (andrej) - Saturday, 22 October 2011, 18:08 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 15 May 2017, 17:14 GMT
Task Type Bug Report
Category Arch Projects
Status Closed
Assigned To Andrea Scarpino (BaSh)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No



After building and updating a couple of packages successfully, srcpac --noconfirm -Syubbb starts to spin around GCC and gcc-libs for an extremely long time, building it repeatedly, failing each time and retrying it. Since the package did not need to be updated, this is an obvilus bug. (It is up-to-date and should not be built at all.) After a couple of hours of building gcc-libs (which keeps failing for some reason), I stopped the build process, so I don't know whether it would eventually make progress or not.

This happens on a system which has the *-multilib versions of all the GCC packages installed (so that {bin,lib}32-* packages can be built).

Additional info:
* package version(s)

srcpac-git 20111022-1

Steps to reproduce: srcpac --noconfirm -Syubbb
This task depends upon

Closed by  Doug Newgard (Scimmia)
Monday, 15 May 2017, 17:14 GMT
Reason for closing:  None
Additional comments about closing:  Removed from repos
Comment by Andrea Scarpino (BaSh) - Sunday, 23 October 2011, 07:01 GMT
  • Field changed: Summary ([srcpac-git] spins around gcc-libs all the time → [srcpac] spins around gcc-libs all the time)
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Severity (Medium → High)
  • Task assigned to Andrea Scarpino (BaSh)
This is a bug with provides() (srcpac ignores them) and ATM I've no idea on how to fix it :(
Comment by Andrej Podzimek (andrej) - Thursday, 19 January 2012, 13:05 GMT
The following commands create an associative array called 'provides', indexed by package names. The values are either the version of the provided package or 'yes' if no version is explicitly specified in pacman's output.

$ declare -A provides
$ eval $(for i in $(LC_ALL=C pacman -Qi | grep Provides | grep -v None | cut -d: -f2); do echo $i | awk -F = '{print "provides[" $1 "]=" ($2 == "" ? "yes" : $2);}'; done)

After running the two lines above, the array seems to contain the expected data:

$ echo ${provides[x-server]}
$ echo ${provides[libv4l]}

Once you have this array, srcpac could consult it before trying to build package dependencies (if required by -bb or -bbb, of course) and thus avoid the cyclic build attempts.

Unfortunately, this suggestion has an obvious problem: it only works in bash. AFAIK, some other popular shells, such as dash, do not implement associative arrays. (Such a feature might be non-standard.) But still, adding #!/bin/bash and using the associative array would be a nice temporary solution. :-)
Comment by Andrej Podzimek (andrej) - Thursday, 19 January 2012, 13:27 GMT
Ooops, the array also contains some garbage... This happens because too many lines pass through the two greps. Adding a ^ might help:

$ declare -A provides
$ eval $(for i in $(LC_ALL=C pacman -Qi | grep '^Provides' | grep -v None | cut -d: -f2); do echo $i | awk -F = '{print "provides[" $1 "]=" ($2 == "" ? "yes" : $2);}'; done)

Now the array should be valid.
Comment by Andrea Scarpino (BaSh) - Thursday, 19 January 2012, 13:31 GMT
Nice to see some help ;)

Unfortunately I guess I cannot work on it soon.