1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
|
<?xml version="1.0"?>
<guide self="appendices/common-problems/">
<chapter>
<title>Common Problems</title>
<body>
<p>
This page provides suggestions on how to handle various commonly seen errors
and QA notices.
</p>
</body>
<section>
<title>Handling QA Notices</title>
<body>
<p>
The <c>ebuild.sh</c> part of Portage includes a number of checks for common
problems. These can result in a 'QA Notice' message being displayed. You must
not rely upon Portage always generating these messages <d/> they are not a
substitute for proper testing and QA by developers.
</p>
<note>
Some eclasses output messages in the same format. These are not
covered here.
</note>
</body>
<subsection>
<title>QA Notice: USE Flag foo not in IUSE</title>
<body>
<p>
With the exception of 'special' flags (the arch flags and <c>USE_EXPAND</c>
variables), all <c>USE</c> flags used by a package must be included in <c>IUSE</c>.
See <uri link="::ebuild-writing/variables/#IUSE"/> and
<uri link="::general-concepts/use-flags/"/>.
</p>
</body>
</subsection>
<subsection>
<title>QA Notice: foo in global scope</title>
<body>
<p>
This message occurs when various tools are inappropriately used in global scope.
Remember that no external code should be run globally. Depending upon the tool
in use, there are various alternatives:
</p>
<dl>
<dt>
<c>sed</c>, <c>awk</c>, <c>grep</c>, <c>egrep</c>, <c>cut</c> etc
</dt>
<dd>
Usually when any of the above are used in global scope, it is to manipulate
a version or program name string. These should be avoided in favour of pure
<c>bash</c> constructs. The built-in helpers of EAPI 7 are useful here. See
<uri link="::ebuild-writing/variables/#Version and Name Formatting Issues"/>
and <uri link="::tools-reference/bash/#Bash Variable Manipulation"/>.
</dd>
<dt>
<c>has_version</c>, <c>best_version</c>
</dt>
<dd>
Calls to either of these globally indicates a serious problem. You must <b>not</b>
have metadata varying based upon system-dependent information <d/> see
<uri link="::general-concepts/portage-cache/"/>. You should rewrite your ebuilds
to correctly use dependencies.
</dd>
<dt>
<c>python</c>, <c>perl</c> etc
</dt>
<dd>
Ebuilds are <c>bash</c> scripts. Offloading anything you don't know how to do
in <c>bash</c> onto another language is not acceptable <d/> if nothing else,
because not all users will always have a full system when ebuilds are
sourced.
</dd>
</dl>
</body>
</subsection>
<subsection>
<title>QA Notice: foo is setXid, dynamically linked and using lazy bindings</title>
<body>
<p>
Dynamically linked setXid applications should not use lazy bindings when linking
for security reasons. If this message is shown, you have a couple of options:
</p>
<ul>
<li>
Modify the package's Makefile (or equivalent) to use <c>-Wl,-z,now</c> when
linking. This solution is preferred.
</li>
<li>
Use <c>append-ldflags</c> (see <uri
link="::ebuild-writing/functions/src_compile/build-environment#Adding Additional Flags"/>)
to add <c>-Wl,-z,now</c>. This will affect <e>all</e> binaries installed, not just the setXid ones.
</li>
</ul>
</body>
</subsection>
<subsection>
<title>QA Notice: ECLASS foo inherited illegally</title>
<body>
<p>
All eclass inherits must be unconditional, or based purely upon static
machine-independent criteria (<c>PN</c> and <c>PV</c> are most common here). See
<uri link="::general-concepts/portage-cache/"/>.
</p>
<p>
You may see this warning in situations where there is not actually any illegal
inheritance occurring. Most commonly:
</p>
<ul>
<li>
When unmerging a package which was installed using an old Portage version that
did not record inheritance.
</li>
<li>
When working with eclasses in an overlay with a stale cache. See <uri
link="::general-concepts/overlay/#Overlay and Eclasses"/>.
</li>
<li>
When working with a stale Portage cache.
</li>
</ul>
<p>
You should manually check against the rules described in
<uri link="::general-concepts/portage-cache/"/> if
you see this notice locally. If you see this notice when working with a pure
<c>emerge sync</c> over <c>rsync</c> setup, it is probably a genuine issue.
</p>
<todo>
from vapier:
TEXTREL's ... binary files which contain text relocations ... see
'prepstrip' for a full description unsafe files ... basically files that
are setid and writable by Other users i've added the following QA checks to
Portage HEAD (no idea when they'll hit a release): Insecure RUNPATHs ...
binary files which have RUNPATH's encoded in them which are in +t
directories Executable stacks ... binary files whose stack is marked with
+x ... will bomb on amd64 for example
</todo>
</body>
</subsection>
</section>
<section>
<title>Handling <c>repoman</c> Messages</title>
<body>
<todo>
write me
</todo>
</body>
</section>
<section>
<title>Handling Access Violations</title>
<body>
<p>
Portage uses a sandbox for certain phases of the build process. This prevents a
package from accidentally writing outside 'safe' locations. See
<uri link="::general-concepts/sandbox/"/> for details.
</p>
<p>
If a package violates the sandbox, an error such as the following will be given
(assuming that the sandbox is enabled and working on the test system, which
should always be the case for developer boxes):
</p>
<pre>
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/tmp/sandbox-app-misc_-_breakme-1-31742.log"
open_wr: /big-fat-red-error
--------------------------------------------------------------------------------
</pre>
<p>
The <c>open_wr</c> means the package tried to open for write a file that is not
inside write-permitted areas. In this case, the file in question is
<c>/big-fat-red-error</c>.
</p>
<p>
Other error messages exist for read-restricted areas <d/> these are rarely used in
ebuilds.
</p>
<p>
Access violations most commonly occur during the install
phase. Sometimes it is possible to get around the sandbox violations
by tricking the build system into using a safer location. See
<c>src_install</c> and
<uri link="::general-concepts/install-destinations/"/> for discussion.
</p>
</body>
</section>
</chapter>
</guide>
|
GitWeb