Bug 389859 – gnustep-base/gnustep-base-1.22.1[doc] - make[1]: *** No rule to make target `ReleaseNotes/dependencies', needed by `internal-doc-all_'. Stop.

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Andrew Savchenko 2011-11-08 08:20:42 UTC]

Hello,

gnustep-base fails to build docs:

Making all for doc ReleaseNotes...
../Tools/obj/autogsdoc -Project ReleaseNotes -DocumentationDirectory ReleaseNotes  -MakeDependencies ReleaseNotes/dependencies ReleaseNotes.gsdoc
The file '/var/tmp/portage/gnustep-base/gnustep-base-1.22.1/temp/GNUstep.conf' is writable by someone other than its owner (permissions 0664).
Ignoring it.
make[1]: *** No rule to make target `ReleaseNotes/dependencies', needed by `internal-doc-all_'.  Stop.
make: *** [ReleaseNotes.all.doc.variables] Error 2

With USE="-doc" it builds fine.

[Comment 1 Andrew Savchenko 2011-11-08 08:21:05 UTC]

Created attachment 291933 [details]
build.log

[Comment 2 Andrew Savchenko 2011-11-08 08:21:17 UTC]

Created attachment 291935 [details]
environment

[Comment 3 Andrew Savchenko 2011-11-08 08:21:31 UTC]

Created attachment 291937 [details]
emerge --info

[Comment 4 Bernard Cafarelli 2011-11-18 14:35:28 UTC]

I have committed a fix to gnustep-base.eclass that fixes a sandbox violation (on tex fonts cache), but that's not the problem we have here...

I suspect some of the user* FEATURES, as here without them the GNUstep.conf has correct permissions (644). I'll try to reproduce it

[Comment 5 Bernard Cafarelli 2012-02-16 13:12:01 UTC]

Portage team, maybe you can help:

in gnustep-base.eclass, most phases begin with an environment check, which creates (if it does not already exists) ${T}/GNUstep.conf (to set temporary settings for sandboxing).

Here for gnustep-base, it is created in src_configure(). However with FEATURES="userpriv usersandbox", at the end of src_configure the file has 664 permissions (the original is copied from /etc/GNUstep/GNUstep.conf and is 644).

Apparently permissions for files in ${T} change at the end of the phase. But later in src_install(), the build system checks the GNUstep.conf and ignores it because of its incorrect permissions.

So is there a way to keep the file permissions? I could do a chmod at the beginning of other phases, but that's more of a workaround.

[Comment 6 Zac Medico 2012-02-16 15:12:39 UTC]

(In reply to comment #5)
> Apparently permissions for files in ${T} change at the end of the phase. But
> later in src_install(), the build system checks the GNUstep.conf and ignores it
> because of its incorrect permissions.
> 
> So is there a way to keep the file permissions? I could do a chmod at the
> beginning of other phases, but that's more of a workaround.

If you instead use ${WORKDIR}/GNUstep.conf then the permissions will be preserved.

[Comment 7 Bernard Cafarelli 2012-02-16 16:34:14 UTC]

Created attachment 302175 [details, diff]
gnustep-base.eclass patch

[Comment 8 Bernard Cafarelli 2012-02-16 16:45:43 UTC]

Indeed, that's a better way.

Paweł, can you test with the attached patch to gnustep-base.eclass if this changes something to your sandbox problem? Thanks

I will do some checks on the gnustep-* ebuilds before committing the change

[Comment 9 Paweł Hajdan, Jr. (RETIRED) 2012-02-19 10:54:00 UTC]

(In reply to comment #8)
> Paweł, can you test with the attached patch to gnustep-base.eclass if this
> changes something to your sandbox problem? Thanks

I can't reproduce bug #383665 now (without the patch). Not sure why. I didn't test the patch.

[Comment 10 Bernard Cafarelli 2012-02-20 10:16:11 UTC]

Ok, thanks. I committed the patch so this bug at least is fixed. Thanks everyone