Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 263402 - app-cdr/dvd+rw-tools: kernel complains about growisofs using 32-bit capabilities (legacy support in use)
Summary: app-cdr/dvd+rw-tools: kernel complains about growisofs using 32-bit capabilit...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it
URL:
Whiteboard:
Keywords: NeedPatch
Depends on:
Blocks:
 
Reported: 2009-03-22 19:22 UTC by Raphaël Droz
Modified: 2019-04-29 08:30 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch to make growisofs use of libcap (dvd+rw-tools-7.0-sys_caps.patch,668 bytes, patch)
2009-03-22 19:23 UTC, Raphaël Droz
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Raphaël Droz 2009-03-22 19:22:16 UTC
When burning a dvd image, dmesg throws the following line :
warning: `growisofs' uses 32-bit capabilities (legacy support in use)

This is because growisofs should include the libcap (<sys/capability.h>) header instead of the <linux/capability.h>


Reproducible: Always

Steps to Reproduce:




The following patch make growisofs use the correct header.
The warning doesn't appears anymore.
The ebuild should also be modified to depends upon sys-libs/libcap

After some hesitation I put selected 'All' as 'Hardware plateform' as I'm not sure it's amd64 specific.
Comment 1 Raphaël Droz 2009-03-22 19:23:54 UTC
Created attachment 185904 [details, diff]
patch to make growisofs use of libcap
Comment 2 Raphaël Droz 2009-03-28 11:57:16 UTC
Sadly I was wrong, the warning still appears (here with a fresh 2.6.29).
I still think that the fix was a right thing (compiling against the libcap) anyway it doesn't do what it was expected to do.
Anyone who already came deeply into the growisofs code to give any hint ?
Comment 3 Raphaël Droz 2009-03-28 13:01:30 UTC
Seems that the linux sources capability.h (/usr/src/linux/include/linux/capability.h) have :
#define _KERNEL_CAPABILITY_VERSION _LINUX_CAPABILITY_VERSION_3
#define _KERNEL_CAPABILITY_U32S    _LINUX_CAPABILITY_U32S_3
So the patch should also replace the l. 849 of growisofs.c from :
h.version       = _LINUX_CAPABILITY_VERSION;
to :
h.version       = _KERNEL_CAPABILITY_VERSION;
BUT :
1) _KERNEL_CAPABILITY_VERSION is defined in both 2.6.28 and 2.6.29 kernel sources but NOT in sys-kernel/linux-headers-2.6.28-r1 (can't understand why).
2) I don't know which changes in the growisofs would be needed to comply with the _LINUX_CAPABILITY_VERSION_3

Comment 4 Raphaël Droz 2009-03-28 15:03:20 UTC
(In reply to comment #3)
Replying myself again (sorry for flooding media-optical)
I fear my understanding of the kernel include generation stuff increase the probability this bug going INVALID sooner or later :)
The _KERNEL_CAPABILITY_VERSION is stripped by scripts/unifdef -U__KERNEL__ during headers build.
I also found this thread.
http://fixunix.com/kernel/367088-why-so-many-unexported-headers-checking-__kernel__.html
Not yet sure, but the ifndef __KERNEL__ means that any userland applications which compile against the <linux/capability.h> (even via <sys/capability.h> are stuck with this warning (and it's consequences I was not able to evaluate).
The result of a "make headers_install" of the vanilla sources should not be different.
So as digest, linux/capability.h restricts _KERNEL_CAPABILITY_VERSION to ifdef __KERNEL__ and hardcode _LINUX_CAPABILITY_VERSION to 1, I can't get the logic but it seems like the insights depends more on linux/capability.h than growisofs.c
Notice : with the current linx header, changing _LINUX_CAPABILITY_VERSION to _KERNEL_CAPABILITY_VERSION (as said before) make the compilation obviously fails.
Comment 5 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2019-04-29 08:30:21 UTC
Closing this after ten years of rotting in our bugzilla. If this is still an issue nowadys, a new bug should be filed.