| Summary: | dev-lang/tcc-0.9.26_pre1 - access violation in install tcc-doc.info /usr/share/info | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Samuel Bauer <samuel.bauer> |
| Component: | [OLD] Development | Assignee: | Maintainers for Miscelleneous Language Packages [OBSOLETE] <lang-misc+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dan, jason.mours, patrick |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
tcc-0.9.26_pre1.ebuild.patch |
||
Created attachment 337470 [details, diff]
tcc-0.9.26_pre1.ebuild.patch
Sets DESTDIR="${D}" in make install to fix write deny
I can confirm it works. docdir="${D}"/usr/share/doc/${PF} \
that's already in the ebuild, and I cannot reproduce the failure.
... so what makes our systems different enough so that you can make it fail?
My gentoo install isn't modified in any manner for /usr/ directory. It's quite old (~5years), but has been maintained up to date regulary since my last install. Another user (comment #2), seems to encounter this problem. I don't think one need to use ${D} for each install directory, at the risk to have a missing one, but rather to set it "globally" through DESTDIR="${D}". It the common way used by EAPI4 (I think it's same in EAPI5 used by this ebuild) in src_install. (In reply to comment #3) > docdir="${D}"/usr/share/doc/${PF} \ > > that's already in the ebuild, and I cannot reproduce the failure. > > ... so what makes our systems different enough so that you can make it fail? I just experienced this bug as well. The failure is because the tcc configure script only uses ${infodir} to create a canonical path for info files so docdir="${D}"/usr/share/doc/${PF} \ has no effect. I added infodir="${D}"/usr/share/info/${PF} \ to the ebuild to correct the problem which I believe is "more correct" than specifying DESTDIR="${D}". Is the patch going to be pushed to portage? I'm having tcc problems with my build server, and while I'm not apposed to using ~amd64 testing, I won't use a patch unless it's in portage on this machine. + 16 Apr 2013; Patrick Lauer <patrick@gentoo.org> tcc-0.9.26_pre1.ebuild: + Fix for sandbox violation #454874 Reproduced, and fixed |
Created attachment 337468 [details] build.log Write deny