[Jaunty] trying to overwrite `/usr/include/drm/drm_sarea.h', which is also in package libdrm-dev

Confirmed here.

looks like commit 2e57d2db4a168f427813001700d90f2de1cdc550 is the reason. Debian does not have drm/* in their package...

Confirmed that they should be dropped from libdrm.

It seems that this is caused by our sync of behaviour to debian pulling in all of the exported header files. It seems that libdrm-dev has its own copies and right now they are not actually just copies of the kernel ones. In the short term we probabally will have to pull out the kernel copies until this interaction is sorted out.

I have prepared a kernel patch to remove the drm headers temporarily. However during that it was pointed out that if we are intending on using the kernel headers in the longer term it might be more appropriate to use a dpkg-divert on the few headers that actually are functionally different. Most seem very similar and might be left. We need someone from the libdrm-dev maintainers to have a look and see if that seems feasable. The dash package has some examples of how this could be achieved.

discussion on IRC coalesced around changing libdrm-dev as the short-term solution:

08:17 < cjwatson> so the short-term answer is to use the files in libdrm-dev instead, then?
08:17 < apw> i think that is the low risk strategy for the -alpha2 milestone
08:18 < cjwatson> I agree; in that case, remove the files from linux-libc-dev and upload libdrm-dev with Replaces: linux-libc-dev (<< first-version-without-those-files)
08:18 < apw> it sounded like there is a push with the consumers of these headers to fix the headers in the kernel or the consumer packages to cope, but i don't think its going to be instant
08:18 < apw> the bug is also occuring in debian upstream too
08:18 < pitti> cjwatson: why a libdrm-upload in this case?
08:20 < cjwatson> because it's the right thing to do - otherwise people with the old linux-libc-dev installed might get errors on upgrade

After alpha-2, we can revisit trying to get working headers into l-l-d and dropping them from libdrm-dev.

Note that libdrm-dev's Replaces: needs to be versioned, otherwise there's the possibility that dpkg will silently omit the l-l-d copies of the headers on upgrade. So in this case, we probably want Replaces: linux-libc-dev (<= 2.6.28-3.4), making a good-faith assumption that this will be "resolved" in some sense for the next linux upload.

This bug was fixed in the package libdrm - 2.4.1-0ubuntu8

---------------
libdrm (2.4.1-0ubuntu8) jaunty; urgency=low

  * libdrm-dev: Replace linux-libc-dev (<= 2.6.28-3.4), since it
    includes the drm headers. We will drop them from libdrm-dev
    after jaunty alpha2 when the drivers support the new headers.
    (LP: #308387)

 -- Timo Aaltonen <email address hidden> Tue, 16 Dec 2008 23:29:38 +0200

This bug also affects intrepid: linux-libc-dev 2.6.27-11.21 from intrepid-proposed conflicts with libdrm 2.3.1-0build1.

I can confirm this from intrepid-proposed:
E: /var/cache/apt/archives/linux-libc-dev_2.6.27-11.21_i386.deb: trying to overwrite `/usr/include/drm/drm_sarea.h', which is also in package libdrm-dev

I can also confirm this bug affects intrepid

This bug affects the kernel package in -proposed:

 Unpacking replacement linux-libc-dev ...
 dpkg: error processing /space/cache/apt/archives/linux-libc-dev_2.6.27-11.21_i386.deb (--unpack):
  trying to overwrite `/usr/include/drm/drm_sarea.h', which is also in package libdrm-dev

tagged as regression-proposed and targeted for Intrepid.

The intrepid side of this should be resolved. The patch was reverted there. The Jaunty side should also be temporarily resolved via a Replaces: marker on an updated libdrm-dev package. We are expecting the fixes for the affected userspace consumers of these headers either as changes to the kernel or those userspace tools trickling in from upstream.

I guess the libdrm task must be reopened since the temporary workaround broke with 2.6.28-4.

Confirmed; I've just run into this in an intrepid -> jaunty upgrade today.

Unpacking replacement linux-libc-dev ...
dpkg: error processing /var/cache/apt/archives/linux-libc-dev_2.6.28-4.5_amd64.deb (--unpack):
 trying to overwrite `/usr/include/drm/drm_sarea.h', which is also in package libdrm-dev
dpkg-deb: subprocess paste killed by signal (Broken pipe)

Here's the change I did to get my upgrade to go.

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=81125a853a3e44b9b26bd0fc0714174d698ca604

This bug was fixed in the package linux - 2.6.28-4.6

---------------
linux (2.6.28-4.6) jaunty; urgency=low

  [ Tim Gardner ]

  * Enable CONFIG_X86_E_POWERSAVER=m for i386 generic
    - LP: #237405
  * Build i386 AGP drivers as modules
    - LP: #312721
  * Build i386 DRM as a module
    - LP: #312721

  [ Upstream Kernel Changes ]

  * drm/i915: Add missing userland definitions for gem init/execbuffer.
    - LP: #308387

 -- Tim Gardner <email address hidden> Mon, 29 Dec 2008 09:16:47 -0700

This bug was fixed in the package libdrm - 2.4.1-0ubuntu9

---------------
libdrm (2.4.1-0ubuntu9) jaunty; urgency=low

  * debian/libdrm-dev.install: Don't install the drm headers anymore,
    the drivers should build against the ones provided by the kernel.
    (LP: #308387)

 -- Timo Aaltonen <email address hidden> Fri, 02 Jan 2009 12:48:40 +0200

When I tried to compile xserver-xorg-video-intel in jaunty (to include a temporary fix to make it work on my laptop (freedesktop.org bug #17292)), I found that it needed libdrm-2.4.3, and I ended up having to do a lot of convoluted copying of include files, kernel package builds, a libgl1-mesa rebuild, etc, just to get it to compile and (sort of?) work, mainly because of the fact that the drm includes came from linux-libc-dev instead of libdrm-dev. I found it very messy to have to deal with...

With the kernel package so dependent on libdrm, it would make more sense for the include files to come from libdrm-dev, and the kernel build-deps to include libdrm-dev and to use those include files instead of making a copy of its own, imho...

No, they are kernel headers, and belong in the same package where the other kernel headers come from. In your case the build against the kernel headers failed because they needed a patch from upstream, which the latest kernel already has.

Ah, there is a new kernel package that now includes the 'struct drm_drawable_info' from libdrm, but it is still missing 'drm_i915_flip_t' which xserver-xorg-video-intel-2.5.1 needs and which can be found in libdrm-2.4.3/shared-core/i915_drm.h

Apparently, the libdrm include files in the kernel package still isn't up-to-date...

So I'll have ignore the packaging system and manually do the convoluted stuff I mentioned above, or wait more... before I can build a xserver-xorg-video-intel that works for me.

Which is exactly the point I'm making...

Ignore the above, It wasn't xserver-xorg-video-intel that needed the 'drm_i915_flip_t', but libdrm-2.4.3. After reverting back the libdrm package to 2.4.1 form the jaunty repo it now builds works.

Thanks. (but I can't help but feel that this is a bit more complex than it could be).

Aww...

xserver-xorg-video-intel does need drm_i915_flip_t to be defined. It refers to it in "src/i830_dri.c" line 1162, and that struct is supposed to be defined in /usr/include/drm/i915_drm.h, but the latest linux-libc-dev (version 2.6.28-4.10) does not have that yet...

In libdrm-2.4.1 (and newer), that symbol is defined in shared-core/i915_drm.h

I just updated to latest linux-libc-dev in jaunty, but it does not have that symbol.

I can copy the struct manually as defined in i915_drm.h from the libdrm tar, and then the driver builds and appears to work.

Another 'upstream patch' seems needed, to add this struct.

Reopening as it seems more work is needed in the kernel package

there are some commits needed to make it build using the kernel headers. I heard that this is needed, but it doesn't have the flip stuff, so waiting for that:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dfef2459225

I think the installability problems are resolved, so this wouldn't be a blocker for alpha-3. If I'm mistaken, please reset the milestone.

Could we keep the nouveau drm headers:
nouveau_dma.h
nouveau_drm.h
nouveau_reg.h
nouveau_swmthd.h
nv50_grctx.h
in the libdrm-dev package? These headers aren't likely to be shipped with the kernel anytime soon, and the nouveau drivers that we've synced from Debian require them to build.

linux-libc-dev still needs to be updated to have a Replaces: on the intrepid version of libdrm-dev, to ensure a smooth upgrade.

The breakage that occurred with the packages in intrepid-proposed has been addressed, removing the regression-proposed tag.

Added Replaces: libdrm-dev

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=59396efd00d4ae681f370d278d7d84b4b265d720

Uploaded linux_2.6.28-8.21 (forgot to add the LP number in the changelog)

Intrepid Ibex reached end-of-life on 30 April 2010 so I am closing the
report. The bug has been fixed in newer releases of Ubuntu.