Summary: | x11-libs/gtk+-2.18.7 emerge fails with app-vim/cvsmenu installed due to sandbox errors while calling gtkdoc-fixxref | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Graham Murray <graham> |
Component: | [OLD] Library | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 10.0 | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.gnome.org/show_bug.cgi?id=612028 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Build log |
Description
Graham Murray
2010-02-23 20:24:15 UTC
Attach full build log. Did you set any var, that could have such effect ? Further investigation shows that the build works with no problems if I first unmerge =app-vim/cvsmenu-1.147. Re-emerging this and trying again to emerge gtk+ fails as before. Created attachment 221011 [details]
Build log
This is the build log of the failure with =app-vim/cvsmenu-1.147 installed.
Does it happen only with gtk+ or with any package that uses gtk-doc *and* is set to rebuild docs (either by 'doc' useflag or otherwise) ? (In reply to comment #4) > Does it happen only with gtk+ or with any package > that uses gtk-doc *and* is set to rebuild docs > (either by 'doc' useflag or otherwise) ? > It does it with other packages as well, with yesterday's updates it also did it for sys-apps/devicekit-power-0.14. ok, so for some silly reason gtkdoc-fixxref is calling /usr/bin/vim automagically system "echo 'let html_number_lines=0|let html_use_css=1|let use_xhtml=1|syn on|e $temp_source_file|run! syntax/2html.vim|wa!|qa!' | /usr/bin/vim -n -e -u /dev/null -T xterm >/dev/null"; ^ that is being called each time gtkdoc-fixxref is run. But there's a "-n" flag, which means vim should not use any .swp files. So why does it try to write to /usr/share/vim/vimfiles/plugin/.cvsmenu.vim.swp ... (In reply to comment #6) > ok, so for some silly reason gtkdoc-fixxref is calling /usr/bin/vim > automagically > > system "echo 'let html_number_lines=0|let html_use_css=1|let use_xhtml=1|syn > on|e $temp_source_file|run! syntax/2html.vim|wa!|qa!' | /usr/bin/vim -n -e -u > /dev/null -T xterm >/dev/null"; > > ^ that is being called each time gtkdoc-fixxref is run. > > But there's a "-n" flag, which means vim should not use any .swp files. So why > does it try to write to /usr/share/vim/vimfiles/plugin/.cvsmenu.vim.swp ... > ok, so apparently this bug in vim get weirder: that file is only created if vim is called with -u /dev/null . So a workaround is to instead call with -u NONE . I've reported an upstream gtk-doc bug about this: https://bugzilla.gnome.org/show_bug.cgi?id=612028 I've added this to 1.13-r2. Here's documentation about what this is about (figured out thanks to #vim): gtkdoc-fixxref in gtk-doc calls vim (if it is installed) in ex mode to run some commands in HighlightSourceVim(). The invocation is: /usr/bin/vim -n -e -u /dev/null -T xterm -n: Don't use swapfiles -e: Ex mode -u: Use this instead of /etc/vim/vimrc -T: Terminal mode If the user has cvsmenu installed, when vim loads that plugin, the plugin itself causes vim to read the plugin file again, probably here: exec 'read '.CVSEscapePath(a:filename) This causes vim to write a swapfile in the same place (inspite of -n). This however, only happens if you use -u /dev/null (why it doesn't happen without that is a mystery). Easiest, and the most correct solution is to use -u NONE instead, which prevents vimrc and plugins both from being loaded. The patch committed does exactly this. |