Bugzilla Bug 196836

media-libs/libprojectm-1.01 ~mips and ~hppa keyword dropped because
media-libs/glew isn't keyworded, please keyword both.

bsd, you also need media-libs/glew, keywords not dropped.

I checked in a patch for FreeBSD (use stdlib.h instead of malloc.h) - not sure
if these other archs need this.  It's #ifdef'd for only FreeBSD right now.

Also, I added the dep to media-libs/glew, and I keyworded that package.  We
should test, though - what's the best way?

In addition, I get one collision warning:

 * This package will overwrite one or more files that may belong to other
 * packages (see list below). Add "collision-protect" to FEATURES in
 * make.conf if you would like the merge to abort in cases like this. You
 * can use a command such as `portageq owners / <filename>` to identify
 * the installed package that owns a file. If portageq reports that only
 * one package owns a file then do NOT file a bug report. A bug report is
 * only useful if it identifies at least two or more packages that are
 * known to install the same file(s). If a collision occurs and you can
 * not explain where the file came from then you should simply ignore the
 * collision since there is not enough information to determine if a real
 * problem exists. Please do NOT file a bug report at
 * http://bugs.gentoo.org unless you report exactly which two packages
 * install the same file(s). Once again, please do NOT file a bug report
 * unless you have completely understood the above message.
 * 
 * Detected file collision(s):
 * 
 *      /usr/share/projectM/presets/Rovastar - Kalideostars (Round  Round
Mix).milk

Both marked ~hppa. Sadly, the package that's the reason for libprojectm's
keywording for hppa (audacious/-plugins) cannot be tested against this new
version because of apparent API incompatibilities.

Note: I was advised that changing malloc.h to stdlib.h should not be
conditional, as it is useful for other archs too, so I have just changed the
ebuild to unconditionally make this change.

(In reply to comment #1)
> In addition, I get one collision warning:
> 
>  * This package will overwrite one or more files that may belong to other
>  * packages (see list below). Add "collision-protect" to FEATURES in
>  * make.conf if you would like the merge to abort in cases like this. You
>  * can use a command such as `portageq owners / <filename>` to identify
>  * the installed package that owns a file. If portageq reports that only
>  * one package owns a file then do NOT file a bug report. A bug report is
>  * only useful if it identifies at least two or more packages that are
>  * known to install the same file(s). If a collision occurs and you can
>  * not explain where the file came from then you should simply ignore the
>  * collision since there is not enough information to determine if a real
>  * problem exists. Please do NOT file a bug report at
>  * http://bugs.gentoo.org unless you report exactly which two packages
>  * install the same file(s). Once again, please do NOT file a bug report
>  * unless you have completely understood the above message.
>  * 
>  * Detected file collision(s):
>  * 
>  *      /usr/share/projectM/presets/Rovastar - Kalideostars (Round  Round
> Mix).milk
> 

Indeed, I'm having same issue here but I didn't previously even have
/usr/share/projectM directory so this is a false positive and looks like a
portage bug..

CCing dev-portage.

(In reply to comment #4)
> Indeed, I'm having same issue here but I didn't previously even have
> /usr/share/projectM directory so this is a false positive and looks like a
> portage bug..

It's not a bug, it's a "feature". ;)

As the message attempts to explain, you should just ignore the message if you
are unable to explain where the file came from. You can use portageq to see if
some other package owns the files, in which case it's not a false positive,
it's a real problem.

(In reply to comment #1)
>  *      /usr/share/projectM/presets/Rovastar - Kalideostars (Round  Round
> Mix).milk

Actually, I think this might be related to bug 14983. We can fix the CONTENTS
parser so that it properly handles 2 consecutive spaces in a filename like
that.

The CONTENTS parser is fixed in sys-apps/portage-2.1.3.17 so it can handle
almost anything except newlines in filenames.

(In reply to comment #7)
> The CONTENTS parser is fixed in sys-apps/portage-2.1.3.17 so it can handle
> almost anything except newlines in filenames.
> 

Thanks Zac.

(In reply to comment #1)
> I checked in a patch for FreeBSD (use stdlib.h instead of malloc.h) - not sure
> if these other archs need this.  It's #ifdef'd for only FreeBSD right now.

I've mailed the malloc patch in tree to upstream.

(In reply to comment #2)
> Both marked ~hppa. Sadly, the package that's the reason for libprojectm's
> keywording for hppa (audacious/-plugins) cannot be tested against this new
> version because of apparent API incompatibilities.

  31 Oct 2007; Tony Vroon <chainsaw@gentoo.org>
  audacious-plugins-1.2.2-r1.ebuild, audacious-plugins-1.2.5.ebuild,
  audacious-plugins-1.3.3.ebuild, audacious-plugins-1.3.4.ebuild,
  audacious-plugins-1.3.5.ebuild, +audacious-plugins-1.4.0_beta4.ebuild:
  Add 1.4.0 beta 4. Removed projectm dependencies across the board to avoid
  dependency ping pong games.

But it might be readded to final 1.4.0, and it will be this version.

So overall, everything except ~mips keyword dropping things are resolved here.
I'm reassining it to them.

nothing is using this since old audacious is leaving portage which was the
reason for keywording in first place.. mips has no need for this orphaned
library, imho