FS#21354 - [xmms2] pacman -Syu ==> NOT included depencies (with reasons): sidplay 2

Attached to Project: Community Packages
Opened by David C. Rankin (drankinatty) - Tuesday, 19 October 2010, 21:17 GMT
Last edited by Sergej Pupykin (sergej) - Thursday, 21 October 2010, 13:15 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Architecture All
Severity Low
Priority Low
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

A system update tonight provided the following note:

==> NOT included depencies(with reasons):
- sidplay - we do not have sidplay 2 series in repos; also it's
somehow connected with resid i guess(not in repos also)

this is the first time I've seen this and it looks like pacman got confused
looking for the sidplay 2 series package. What I don't understand is:

"also it's somehow connected with resid i guess(not in repos also)"

Bug filed as request of Allan -> suggests a packaging problem.

Additional info:

This occurred during an update on an i686 box

Steps to reproduce:

pacman -Syu

pacman.log (bzipped) attached:
   pacman-1018.log.bz2 (36.7 KiB)
This task depends upon

Closed by  Sergej Pupykin (sergej)
Thursday, 21 October 2010, 13:15 GMT
Reason for closing:  Fixed
Additional comments about closing:  message about sidplay was removed from .install
Comment by Ionut Biru (wonder) - Tuesday, 19 October 2010, 21:24 GMT
xmms2 has optdepends and a message in .install about sidplay.

please remove them
Comment by Ray Rashif (schivmeister) - Tuesday, 19 October 2010, 21:30 GMT
  • Field changed: Summary ([xmms2]pacman -Syu ==> NOT included depencies (with reasons): sidplay 2 → pacman -Syu ==> NOT included depencies (with reasons): sidplay 2)
  • Field changed: Severity (Medium → Low)
  • Field changed: Priority (Normal → Low)
You probably got confused because the message is lost within the rest of pacman's output, but that's normal for package scriptlet messages (in this case xmms2).

The issue here is more of a presentation matter. A slight change of wording so that it doesn't mislead users into thinking it's a pacman error should fix this (or remove the message/scriptlet if it's not important).
Comment by David C. Rankin (drankinatty) - Wednesday, 20 October 2010, 02:31 GMT
Thanks guys, I was just going to drop a note that I also confirmed this on x86_64 this evening -- but I guess you know that :p

Loading...