Re: xorg intel package bug?
2014-08-19 12:18 GMT+02:00 Vincent Cheng <vcheng@debian.org>:
>
> Hi,
>
> (Cc-ing debian-x@l.d.o)
>
> On Mon, Aug 18, 2014 at 5:08 AM, BubuXP <bubuxp@gmail.com> wrote:
> > While compiling upstream snapshots for debian
> > https://drive.google.com/folderview?id=0B7AdLMiZn4FzdGZNV2FpLWhPTkk
> > I found that valgrind is disabled.
> > Is this the expected behavior?
> > I'm not a programmer, just a power user, but reading in the debian/rules
> > file it has the following code:
> >
> >
> > DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
> >
> > ifeq ($(DEB_HOST_ARCH), linux)
> > valgrind = --enable-valgrind
> > else
> > valgrind = --disable-valgrind
> > endif
> >
> >
> > DEB_HOST_ARCH will report 'amd64' or 'i386' as values, but it will never be
> > equal to 'linux' so valgrind will be always disabled. I suspect that instead
> > of DEB_HOST_ARCH you should use the DEB_HOST_ARCH_OS variable, that reports
> > 'linux' as value.
>
> Nice catch, thanks!
>
> (I guess that leads to another question, i.e. should we be building
> xserver-xorg-video-intel with --enable-valgrind by default? It looks
> like the change was added in 2:2.21.14-1, although due to the above
> typo xxv-intel in both sid and experimental have always been built
> with --disable-valgrind, and that's also the upstream default.)
In version 2:2.21.14-1 valgrind was enabled by default, but after a
couple of hours version 2:2.21.14-2 was released with "Don't enable
valgrind on kfreebsd" in changelog.
So I think the above lines in debian/rules must change in:
DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
ifeq ($(DEB_HOST_ARCH_OS), linux)
to do the right thing.
> > BTW, do you think it's ok to upload an updated xserver-xorg-video-intel
> > package to the wheezy-backports repository? I compiled it successfully in
> > wheezy, it only required updated drm packages to compile but the resulting
> > packages were ok with the version in wheezy.
>
> Perhaps someone on the list may be interested in doing so? If not, you
> can always ask around on debian-backports@l.d.o. I don't really have
> the time to maintain a backport of xxv-intel, and that's just one
> small piece out of all the userspace components that are candidates
> for being backported (I presume that you want these backports for
> improved hardware support?).
>
> It's also worth noting that your link above suggests that you've
> backported the current xxv-intel package in experimental, whereas only
> packages in testing are eligible to be backported via
> debian-backports.
I didn't know that only 'testing' packages could be backported, good to know.
But frankly I think the intel driver in testing is pretty outdated. An
official snapshot like the current 2.99.914 should be uploaded to
unstable and then in testing (it's quite stable in my opinion).
Another question: in the build log
https://docs.google.com/file/d/0B7AdLMiZn4FzY1c1MU1GMnlZWGs/ there are
these warnings:
dpkg-shlibdeps: warning:
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should
not be linked against libX11-xcb.so.1 (it uses none of the library's
symbols)
dpkg-shlibdeps: warning:
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should
not be linked against libxcb-dri2.so.0 (it uses none of the library's
symbols)
dpkg-shlibdeps: warning:
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should
not be linked against libxcb-util.so.0 (it uses none of the library's
symbols)
dpkg-shlibdeps: warning:
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should
not be linked against libxcb.so.1 (it uses none of the library's
symbols)
dpkg-shlibdeps: warning:
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should
not be linked against libdrm_intel.so.1 (it uses none of the library's
symbols)
dpkg-shlibdeps: warning:
debian/xserver-xorg-video-intel/usr/bin/intel-virtual-output should
not be linked against libpixman-1.so.0 (it uses none of the library's
symbols)
dpkg-gencontrol: warning: Depends field of package
xserver-xorg-video-intel-dbg: unknown substitution variable
${shlibs:Depends}
Are these Debian-related or should be fixed upstream?
Reply to: