vte.c:3683: Warning: Vte: invalid annotation option: tranfer <unknown>:: Warning: Vte: Unknown namespace for identifier 'vte_char_attributes' vte.h:27: Warning: Vte: symbol='__VTE_VTE_H_INSIDE__': Unknown namespace for symbol '_VTE_VTE_H_INSIDE__' vte.h:528: Warning: Vte: symbol='__VTE_VTE_H_INSIDE__': Unknown namespace for symbol '_VTE_VTE_H_INSIDE__' ACCESS DENIED open_wr: /dev/mem Reproducible: Always Steps to Reproduce: 1. emerge =x11-libs/vte-0.30.1-r3 2. 3. Actual Results: Emerge fail. Expected Results: Updated vte.
Created attachment 300451 [details] build.log
Created attachment 300453 [details] environment
What version of dev-libs/gobject-introspection are you using?
Created attachment 300455 [details] info
Created attachment 300457 [details] pqv
(In reply to comment #3) > What version of dev-libs/gobject-introspection are you using? =dev-libs/gobject-introspection-1.30.0-r2
> vte.c:3683: Warning: Vte: invalid annotation option: tranfer > <unknown>:: Warning: Vte: Unknown namespace for identifier > 'vte_char_attributes' > vte.h:27: Warning: Vte: symbol='__VTE_VTE_H_INSIDE__': Unknown namespace for > symbol '_VTE_VTE_H_INSIDE__' > vte.h:528: Warning: Vte: symbol='__VTE_VTE_H_INSIDE__': Unknown namespace for > symbol '_VTE_VTE_H_INSIDE__' These errors are expected and non-fatal (still need to be fixed them at some point I suppose). They will not cause the vte build to die. > ACCESS DENIED open_wr: /dev/mem > sandbox:stop caught signal 2 in pid 27212 > Traceback (most recent call last): > File "/usr/bin/g-ir-scanner", line 46, in <module> > sys.exit(scanner_main(sys.argv)) > File "/usr/lib/gobject-introspection/giscanner/scannermain.py", line 416, in scanner_main > shlibs = create_binary(transformer, options, args) > File "/usr/lib/gobject-introspection/giscanner/scannermain.py", line 320, in create_binary > gdump_parser.parse() > File "/usr/lib/gobject-introspection/giscanner/gdumpparser.py", line 110, in parse > tree = self._execute_binary_get_tree() > File "/usr/lib/gobject-introspection/giscanner/gdumpparser.py", line 167, in _execute_binary_get_tree > subprocess.check_call(args, stdout=sys.stdout, stderr=sys.stderr) > File "/usr/lib/python2.7/subprocess.py", line 506, in check_call > retcode = call(*popenargs, **kwargs) > File "/usr/lib/python2.7/subprocess.py", line 493, in call > return Popen(*popenargs, **kwargs).wait() > File "/usr/lib/python2.7/subprocess.py", line 1270, in wait > pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0) > File "/usr/lib/python2.7/subprocess.py", line 478, in _eintr_retry_call > return func(*args) Now, this is the real problem. For some unknown reason, it appears that a call to python's os.waitpid (which AFAIK is just a dumb wrapper around the C library's waitpid(2)) is trying to write to /dev/mem. I have never heard of such a problem and cannot reproduce it on my amd64 machines. Adding arm and toolchain to the CC list, hopefully they can help figure out what is going on.
that log doesn't contain the entire sandbox error. please don't hit CTRL+C in the middle -- let the build finish.
(In reply to comment #8) > that log doesn't contain the entire sandbox error. please don't hit CTRL+C in > the middle -- let the build finish. about 3-4 hours build stop on: ACCESS DENIED open_wr: /dev/mem
Are you still suffering this on a fully updated system?
I see this error on many apps with introspection, and resolv its by FEATUTES="-sandbox"... :(
(In reply to comment #8) > that log doesn't contain the entire sandbox error. please don't hit CTRL+C > in the middle -- let the build finish. @sandbox, Should sandbox allow /dev/mem access?
there's no reason builds should be attempting to access /dev/mem
/dev/mem crw-r----- 1 root kmem
Are you still suffering this problem?
(In reply to comment #15) > Are you still suffering this problem?
