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

Bug #308387 reported by Alessandro Ghersi on 2008-12-16
40
This bug affects 3 people
Affects Status Importance Assigned to Milestone
DRI
Fix Released
Critical
libdrm (Ubuntu)
High
Unassigned
Intrepid
Undecided
Unassigned
Jaunty
High
Unassigned
linux (Ubuntu)
High
Tim Gardner
Intrepid
Undecided
Unassigned
Jaunty
High
Tim Gardner

Bug Description

Kubuntu Jaunty amd64 failed to upgrade linux-libc-dev:

The following packages will be upgraded:
  libglade2.0-cil libglib2.0-cil libgtk2.0-cil linux-libc-dev rar unrar
6 upgraded, 0 newly installed, 0 to remove and 37 not upgraded.
Need to get 2341kB of archives.
After this operation, 291kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://it.archive.ubuntu.com jaunty/main libglib2.0-cil 2.12.7-1ubuntu1 [182kB]
Get:2 http://it.archive.ubuntu.com jaunty/main libgtk2.0-cil 2.12.7-1ubuntu1 [782kB]
Get:3 http://it.archive.ubuntu.com jaunty/main libglade2.0-cil 2.12.7-1ubuntu1 [21,1kB]
Get:4 http://it.archive.ubuntu.com jaunty/main linux-libc-dev 2.6.28-3.4 [734kB]
Get:5 http://it.archive.ubuntu.com jaunty/multiverse rar 1:3.8.0-2 [521kB]
Get:6 http://it.archive.ubuntu.com jaunty/multiverse unrar 1:3.8.5-1 [100kB]
Fetched 2341kB in 9s (254kB/s)
(Reading database ... 206495 files and directories currently installed.)
Preparing to replace libglib2.0-cil 2.12.1-1ubuntu2 (using .../libglib2.0-cil_2.12.7-1ubuntu1_amd64.deb) ...
Unpacking replacement libglib2.0-cil ...
Preparing to replace libgtk2.0-cil 2.12.1-1ubuntu2 (using .../libgtk2.0-cil_2.12.7-1ubuntu1_amd64.deb) ...
Unpacking replacement libgtk2.0-cil ...
Preparing to replace libglade2.0-cil 2.12.1-1ubuntu2 (using .../libglade2.0-cil_2.12.7-1ubuntu1_amd64.deb) ...
Unpacking replacement libglade2.0-cil ...
Preparing to replace linux-libc-dev 2.6.28-2.3 (using .../linux-libc-dev_2.6.28-3.4_amd64.deb) ...
Unpacking replacement linux-libc-dev ...
dpkg: error processing /var/cache/apt/archives/linux-libc-dev_2.6.28-3.4_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)
Preparing to replace rar 1:3.8.0-1 (using .../rar_1%3a3.8.0-2_amd64.deb) ...
Unpacking replacement rar ...
Preparing to replace unrar 1:3.8.4-1 (using .../unrar_1%3a3.8.5-1_amd64.deb) ...
Unpacking replacement unrar ...
Processing triggers for man-db ...
Errors were encountered while processing:
 /var/cache/apt/archives/linux-libc-dev_2.6.28-3.4_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Related branches

Martin Pitt (pitti) wrote :

Confirmed here.

Changed in linux:
status: New → Triaged
Timo Aaltonen (tjaalton) wrote :

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

Timo Aaltonen (tjaalton) wrote :

Confirmed that they should be dropped from libdrm.

Andy Whitcroft (apw) wrote :

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.

Changed in linux:
assignee: nobody → apw
status: New → In Progress
Andy Whitcroft (apw) wrote :

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.

Steve Langasek (vorlon) wrote :

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.

Changed in libdrm:
milestone: none → jaunty-alpha-2
Launchpad Janitor (janitor) wrote :

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

Changed in libdrm:
status: Triaged → Fix Released
Marius Gedminas (mgedmin) wrote :

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

Alex Maguran (amaguran) wrote :

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

patmalcolm91 (patmalcolm91) wrote :

I can also confirm this bug affects intrepid

Matt Zimmerman (mdz) wrote :

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.

Andy Whitcroft (apw) wrote :

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.

Changed in linux:
status: New → Fix Committed
Tormod Volden (tormodvolden) wrote :

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

Changed in libdrm:
status: Fix Released → Confirmed
Bryce Harrington (bryce) wrote :

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)

Changed in libdrm:
importance: Undecided → High
status: Confirmed → Triaged
Bryce Harrington (bryce) wrote :

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

Tim Gardner (timg-tpi) wrote :
Changed in linux:
assignee: apw → timg-tpi
importance: Undecided → High
milestone: none → jaunty-alpha-3
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in linux:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in libdrm:
status: Triaged → Fix Released
Jelle Foks (jellefoks) wrote :

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...

Timo Aaltonen (tjaalton) wrote :

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.

Jelle Foks (jellefoks) wrote :

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...

Jelle Foks (jellefoks) wrote :

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).

Jelle Foks (jellefoks) wrote :

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.

Matt Zimmerman (mdz) wrote :

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

Changed in linux:
status: Fix Released → Triaged
Timo Aaltonen (tjaalton) wrote :

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

Steve Langasek (vorlon) wrote :

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.

Changed in linux:
milestone: jaunty-alpha-3 → jaunty-alpha-4

Forwarded from 19542: "Please open another one, hope Jesse could sort out."

../doltcompile gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -I/usr/include/xorg
-I/usr/include/pixman-1 -I/usr/include/drm -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -fno-strict-aliasing -I/usr/include/xorg
-I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/X11/dri
-I../../uxa -DI830_XV -DI830_USE_XAA -DI830_USE_EXA -Wall -g -O2 -MT
i830_dri.lo -MD -MP -MF .deps/i830_dri.Tpo -c -o i830_dri.lo
../../src/i830_dri.c
../../src/i830_dri.c: In function 'I830DRISwapContext':
../../src/i830_dri.c:1168: error: 'drm_i915_flip_t' undeclared (first use in
this function)
../../src/i830_dri.c:1168: error: (Each undeclared identifier is reported only
once
../../src/i830_dri.c:1168: error: for each function it appears in.)
../../src/i830_dri.c:1168: error: expected ';' before 'flip'
../../src/i830_dri.c:1174: error: 'flip' undeclared (first use in this
function)
make[5]: *** [i830_dri.lo] Error 1

same kind of an error trying to build mesa (no log nearby though).

Jesse,

Any comment for that? Zhenyu suggests you to make it resolved. I am not make sure if upstream come across such problem. Since Q4 is released, should not come across such problem.

Chris Halse Rogers (raof) wrote :

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.

There's a patch on intel-gfx@ which should fix this by removing the pageflipping support from the driver?

Yeah, applying the page flipping removal is probably the simplest way to solve this. The kernel doesn't support these interfaces anymore anyway, so...

Created an attachment (id=22047)
modified patch

the patch by Owain doesn't apply against 2.6.0, so I had to modify it a bit.

the original one has been committed, so this can be closed.

Changed in dri:
status: Unknown → Fix Released
Steve Langasek (vorlon) wrote :

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

Changed in linux:
milestone: jaunty-alpha-4 → jaunty-alpha-5
Steve Beattie (sbeattie) wrote :

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

Tim Gardner (timg-tpi) wrote :
Changed in linux:
status: Triaged → Fix Committed
Tim Gardner (timg-tpi) wrote :

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

Changed in linux:
status: Fix Committed → Fix Released

I still need this patch for xf86-video-intel-2.6.3 and drm headers of
kernel-2.6.29-0.258.rc8.git2.fc11.i586.

(In reply to comment #5)
> the original one has been committed, so this can be closed.
>

but just committed in 2.7 branch ?

Alex Valavanis (valavanisalex) wrote :

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.

Changed in libdrm (Ubuntu Intrepid):
status: New → Invalid
Changed in linux (Ubuntu Intrepid):
status: Fix Committed → Invalid
Changed in dri:
importance: Unknown → Critical
Changed in dri:
importance: Critical → Unknown
Changed in dri:
importance: Unknown → Critical
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.