Bug 263402

Summary:	app-cdr/dvd+rw-tools: kernel complains about growisofs using 32-bit capabilities (legacy support in use)
Product:	Gentoo Linux	Reporter:	Raphaël Droz <raphael.droz+floss>
Component:	Current packages	Assignee:	No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed>
Status:	RESOLVED OBSOLETE
Severity:	normal	CC:	hsggebhardt, media-optical, polynomial-c, raphael.droz+floss
Priority:	High	Keywords:	NeedPatch
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Attachments:	patch to make growisofs use of libcap

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.