Availability:
- Already in universe and available on applicable archs.
Rationale:
- Allows enabling support for OpenCL in mesa.
Security:
- No files installed suid, sgid.
- No binaries installed in sbin.
- Not a plugin to security sensitive software.
- Not a daemon or opening a sensitive port.
Quality assurance:
- Should work without configuration.
- No debconf questions.
- No long-term outstanding bugs and updates by debian.
The status of important bugs in Debian's, Ubuntu's, and upstream's bug tracking systems must be evaluated. Links to these bug trackers need to be provided in the MIR report. Important bugs must be pointed out and discussed in the MIR report.
https://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;src=libclc;dist=unstable;repeatmerged=0 - No open bugs found.
1 bug found in ubuntu's bug tracker. Likely a user error because with manual bug verification it's shown that the bug is invalid.
Package is used for nvidia and r600 opencl support.
Testsuite cannot run, it requires the proprietary nvidia drivers.
debian/watch is empty, but explained in debian/watch why.
UI standards:
Not applicable.
Dependencies:
clang is in universe, but the clang source package llvm is in main.
Standards compliance:
Should meet standard, no lintian overrides or warnings.
Maintenance:
Simple package, low maintenance effort, and maintained well in Debian.
Background information:
Required to enable opencl support in mesa. Mesa will need clang too, so the added deps will be needed.
Looks mostly fine. But it doesn't re-build on current vivid?
/usr/lib/
!1 = metadata !{metadata !"char", metadata !5}
^
Makefile:244: recipe for target 'nvptx-
Besides that, the metapackage "clang" will have to be promoted to main too. But that should be simple, its llvm-defaults source package is in main already, as is clang-3.6. Which makes me wonder, is it best practices to specify a clang version in your build-depends, or should it be left as just "clang"?