Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
I started a thread on this and was told by a developer (blubb) that this was actually a bug, but I insist that more people would be screaming if it was a real bug happening to everybody, but here we go. First real bug report, so feel free to correct where and to whom I assigned this bug, I am VERY green about this process! Description of Problem: On ebuilds that use scons, I get massive sandbox access violation errors and it ultimately ends in failure... My examples are two fold: media-video/codeine-1.0 -- even though it is in the ebuild that there is a 'fix for multilib issues' I still get these massive errors and ultimate failure: Quote: Checking for kde-config : kde-config was found Checking for kde version : 3.4.2 Checking for the qt library : qt is in /usr/qt/3 Checking for uic : uic was found as /usr/qt/3/bin/uic Checking for moc : moc was found as /usr/qt/3/bin/moc Checking for the qt includes : ok /usr/qt/3/include/ Checking for the kde includes : ok /usr/kde/3.4/include/ Checking for KDElibs 3.3...ok Checking for main() in C++ library xine... yes Checking for xine-lib 1.0...ok Checking for main() in C library Xtst... yes scons: Reading SConscript files ... ACCESS DENIED unlink: /usr/lib/scons/SCons/Platform/posix.pyc ACCESS DENIED open_wr: /usr/lib/scons/SCons/Platform/posix.pyc ACCESS DENIED unlink: /usr/lib/scons/SCons/Tool/default.pyc ACCESS DENIED open_wr: /usr/lib/scons/SCons/Tool/default.pyc ACCESS DENIED unlink: /usr/lib/scons/SCons/Tool/gcc.pyc ACCESS DENIED open_wr: /usr/lib/scons/SCons/Tool/gcc.pyc ACCESS DENIED unlink: /usr/lib/scons/SCons/Tool/cc.pyc ACCESS DENIED open_wr: /usr/lib/scons/SCons/Tool/cc.pyc ACCESS DENIED unlink: /usr/lib/scons/SCons/Tool/g++.pyc ACCESS DENIED open_wr: /usr/lib/scons/SCons/Tool/g++.pyc ACCESS DENIED unlink: /usr/lib/scons/SCons/Tool/c++.pyc ACCESS DENIED open_wr: /usr/lib/scons/SCons/Tool/c++.pyc etc,etc,etc.. for about 200 more files! Then it fails with the following error: Quote: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-media-video_-_codeine-1.0-4310.log" unlink: /usr/lib/scons/SCons/Platform/posix.pyc (symlink to /usr/lib64/scons/SCons/Platform/posix.pyc) open_wr: /usr/lib/scons/SCons/Platform/posix.pyc (symlink to /usr/lib64/scons/SCons/Platform/posix.pyc) unlink: /usr/lib/scons/SCons/Tool/default.pyc (symlink to /usr/lib64/scons/SCons/Tool/default.pyc) open_wr: /usr/lib/scons/SCons/Tool/default.pyc (symlink to /usr/lib64/scons/SCons/Tool/default.pyc) unlink: /usr/lib/scons/SCons/Tool/gcc.pyc (symlink to /usr/lib64/scons/SCons/Tool/gcc.pyc) open_wr: /usr/lib/scons/SCons/Tool/gcc.pyc (symlink to /usr/lib64/scons/SCons/Tool/gcc.pyc) unlink: /usr/lib/scons/SCons/Tool/cc.pyc (symlink to /usr/lib64/scons/SCons/Tool/cc.pyc) open_wr: /usr/lib/scons/SCons/Tool/cc.pyc (symlink to /usr/lib64/scons/SCons/Tool/cc.pyc) unlink: /usr/lib/scons/SCons/Tool/g++.pyc (symlink to /usr/lib64/scons/SCons/Tool/g++.pyc) open_wr: /usr/lib/scons/SCons/Tool/g++.pyc (symlink to /usr/lib64/scons/SCons/Tool/g++.pyc) unlink: /usr/lib/scons/SCons/Tool/c++.pyc (symlink to /usr/lib64/scons/SCons/Tool/c++.pyc) open_wr: /usr/lib/scons/SCons/Tool/c++.pyc (symlink to /usr/lib64/scons/SCons/Tool/c++.pyc) etc,etc,etc.. for about 200 more files! The log file listed just has the unlink/open_wr errors listed in it. I am also trying to write a custom ebuild for a great app called kleansweep and it needs to use scons and it has EXACTLY the same error on my machine! I have tried the following for the scons scons configure prefix=/usr/lib64 -- same results scons configure libsuffix=64 -- same results it always goes for /usr/lib instead of /usr/lib64 and then tries to follow the symlink which is a MAJOR Sandbox Access Violation as far as I can tell. I want codeine and I would like to provide a working ebuild to the coder of kleansweep.. any ideas? Of course, if I do this outside of the ebuild, it works great because the sandbox restrictions are not in place and there are no problems.. but that is not very Gentoo is it Reproducible: Always Steps to Reproduce: 1. emerge -av codeine 2. Watch massive ACCESS DENIED errors fly by 3. Watch as the ebuild CORRECTLY build codeine (or my custom ebuild) 4. Watch, and laugh, as it tries to install what it has just built.. massive errors and NO ebuild failure error, just a red dotted line at the end! Expected Results: Either the Scons config needs to be set up correctly, or the ebuild mechanism needs to be adjusted to allow for a sym link from /usr/lib to /usr/lib64 Portage 2.0.51.22-r2 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r1, 2.6.13-gentoo-r1 x86_64) ================================================================= System uname: 2.6.13-gentoo-r1 x86_64 AMD Athlon(tm) 64 Processor 2800+ Gentoo Base System version 1.6.13 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ftp-mirror.internap.com/pub/gentoo/ http://ftp.ntua.gr/pub/linux/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/temp/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X aac aalib adns alsa apache2 arts artswrappersuid atk avi bash-completion berkdb bitmap-fonts browserplugin bzip2 cdr crypt cups curl dvd dvdread eds emboss encode esd ffmpeg firefox flac foomaticdb fortran gd gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml imagemagick imlib java jikes jpeg junit kde libwww lzw lzw-tiff mad maildir mbox mikmod mozcalendar mozilla mozsvg mp3 mpeg mysql mythtv nas ncurses nfsv4 nls nptl nvidia offensive ogg oggvorbis opengl oss pam pdflib perl png ppds python qt readline real ruby samba sasl sdl server slang speex spell sqlite ssl subtitles subversion svg tcltk tcpd theora tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xine xinerama xml xml2 xmms xpm xprint xscreensaver xv xvid xvmc zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Forgot to mention that I have scons 0.96.1 installed.. I have not tried the Hard masked(~M) 0.96.90 ..... but will if someone thinks it is worth the risk of installing a ~M package
I get the same errors on x86 (athlon-xp) with the klean sweep sample ebuild.
From searching the forums and Google, it looks like quite a few folks are having similar problems with SCons ebuilds in the past few weeks. The packages being built vary, and not all are on AMD64. My emerge of media-sound/ardour-0.99 is failing like this: config.status: creating gdk--config.h config.status: creating gtk--config.h config.status: executing depfiles commands ACCESS DENIED unlink: /usr/lib/scons/SCons/__init__.pyc ACCESS DENIED open_wr: /usr/lib/scons/SCons/__init__.pyc ACCESS DENIED unlink: /usr/lib/scons/SCons/Script/__init__.pyc ACCESS DENIED open_wr: /usr/lib/scons/SCons/Script/__init__.pyc ACCESS DENIED unlink: /usr/lib/scons/SCons/Debug.pyc ACCESS DENIED open_wr: /usr/lib/scons/SCons/Debug.pyc ACCESS DENIED unlink: /usr/lib/scons/SCons/Defaults.pyc ACCESS DENIED open_wr: /usr/lib/scons/SCons/Defaults.pyc ...and many more, all in /usr/lib/scons/SCons It appears that SCons may be attempting to recompile its own Python code as part of ebuilds that use SCons. This is, of course, outside the sandbox, so it fails. I'm fairly new to Portage, and completely unfamiliar with SCons, so I may not be able to determine the root cause. Some forum threads and other bugs that may be related: http://forums.gentoo.org/viewtopic-t-390040-highlight-openwr.html (late in the thread) http://forums.gentoo.org/viewtopic-t-391112-highlight-openwr.html A similar problem, but with bakefile rather than SCons, is discussed at http://thread.gmane.org/gmane.comp.sysutils.bakefile.devel/310 This problem is also documented in this bug: http://bugs.gentoo.org/show_bug.cgi?id=107096 and is also mentioned in a comment to this bug: http://bugs.gentoo.org/show_bug.cgi?id=90735 , although it looks like that bug's initial report was a different problem. Hoping this helps someone figure out the cause and appropriate fix, -Martin McClure
I had this same problem with the kdissert-ebuild, producing those ACCESS DENIED and open_wq/unlink messages. I then found help here: http://bugs.gentoo.org/show_bug.cgi?id=109559 Re-emerging scons did the trick.
Hmm. Before my previous comment on this bug I had tried re-emerging SCons, and it didn't help. However, after seeing Alexander's comment, I tried re-emerging SCons again, and I am now able to emerge Ardour without error. I have no idea why it didn't work the first time, but succeeded the second. Thanks, Alexander! -Martin
dang.. I hate that.. they HAD to have changed something for it to all of a sudden start working. I re-emerged it at least 4 times before reporting this bug. Since this fixes the bug I am inclined to resolve the bug, but since this is my first bug report, is there some protocol for this or should I just close it out? Thanks for everybody's help here.
*** Bug 111584 has been marked as a duplicate of this bug. ***
*** Bug 113854 has been marked as a duplicate of this bug. ***
*** Bug 110700 has been marked as a duplicate of this bug. ***
Closing, re-emerge scons fixes this.
*** Bug 122263 has been marked as a duplicate of this bug. ***
*** Bug 122373 has been marked as a duplicate of this bug. ***
*** Bug 122663 has been marked as a duplicate of this bug. ***
*** Bug 131952 has been marked as a duplicate of this bug. ***
*** Bug 133601 has been marked as a duplicate of this bug. ***
*** Bug 141966 has been marked as a duplicate of this bug. ***
*** Bug 154619 has been marked as a duplicate of this bug. ***
*** Bug 157503 has been marked as a duplicate of this bug. ***
*** Bug 169817 has been marked as a duplicate of this bug. ***
Perhaps the title of this should be changed? My bug (Bug 169817) was not on an AMD64.
*** Bug 171278 has been marked as a duplicate of this bug. ***
*** Bug 187510 has been marked as a duplicate of this bug. ***
(In reply to comment #22) > *** Bug 187510 has been marked as a duplicate of this bug. *** > (In reply to comment #2) > No, it doesn't try to uninstall anything. Re-emerge scons. > > > *** This bug has been marked as a duplicate of bug 107013 *** > Installed versions: 0.97(21:12:37 31/07/07) I always try that first :/ Remerging is not enough, from the comments on this page it looks like you have to remerge _twice_ and if you have to build it twice to solve this problem, then one would think theres a bug in the build system. And even after remerging scons twice, i _STILL_ have the same build error.
(In reply to comment #23) > (In reply to comment #22) > > *** Bug 187510 has been marked as a duplicate of this bug. *** > > > > (In reply to comment #2) > > No, it doesn't try to uninstall anything. Re-emerge scons. > > > > > > *** This bug has been marked as a duplicate of bug 107013 *** > > > > > Installed versions: 0.97(21:12:37 31/07/07) > > I always try that first :/ > > Remerging is not enough, from the comments on this page it looks like you have > to remerge _twice_ and if you have to build it twice to solve this problem, > then one would think theres a bug in the build system. > > And even after remerging scons twice, i _STILL_ have the same build error. > Problem resolved after rm -rf 'ing the entire scons Dir. Then remerging. seems remerging is not sufficient to re-build all the pyc files correctly on its own. This is still a bug somewhat.
*** Bug 189655 has been marked as a duplicate of this bug. ***
*** Bug 189973 has been marked as a duplicate of this bug. ***
*** Bug 190018 has been marked as a duplicate of this bug. ***
*** Bug 190246 has been marked as a duplicate of this bug. ***
*** Bug 190455 has been marked as a duplicate of this bug. ***
*** Bug 190603 has been marked as a duplicate of this bug. ***
*** Bug 191193 has been marked as a duplicate of this bug. ***
*** Bug 191566 has been marked as a duplicate of this bug. ***
*** Bug 192646 has been marked as a duplicate of this bug. ***
I can see this as well (boswars-2.4.1-4889 and ardour-2.0.5 are suffering from this) --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-games-strategy_-_boswars-2.4.1-4889.log" unlink: /usr/lib/scons-0.97/SCons/__init__.pyc unlink: /usr/lib/scons-0.97/SCons/Script/__init__.pyc unlink: /usr/lib/scons-0.97/SCons/Action.pyc unlink: /usr/lib/scons-0.97/SCons/Debug.pyc unlink: /usr/lib/scons-0.97/SCons/Errors.pyc unlink: /usr/lib/scons-0.97/SCons/Executor.pyc unlink: /usr/lib/scons-0.97/SCons/Memoize.pyc unlink: /usr/lib/scons-0.97/SCons/Util.pyc [...] emerge --info Portage 2.1.3.9 (default-linux/x86/2007.0/desktop, gcc-4.2.0, glibc-2.6.1-r0, 2.6.22-gentoo-r5 i686) ================================================================= System uname: 2.6.22-gentoo-r5 i686 AMD Athlon(tm) Processor Timestamp of tree: Sun, 16 Sep 2007 16:50:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r4, 2.5.1-r2 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.10-r4 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18 sys-devel/gcc-config: 1.4.0-r2 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -Os -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=athlon-tbird -Os -pipe" DISTDIR="/var/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp.du.se/pub/os/gentoo http://gentoo.ynet.sk/pub http://mir.zyrianes.net/gentoo/ http://gentoo.inode.at/" LANG="de_DE" LC_ALL="de_DE@euro" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/var/distfiles/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/pro-audio /usr/portage/local/layman/science /usr/local/portage /usr/local/overlays/misc" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="3dnow 3dnowext 3ds 7zip X a52 aac aalib acpi alsa amarok amr apache2 arts artswrappersuid asf auctex audiofile bash-completion berkdb bitmap-fonts blender-game bootsplash branding bzip2 cairo canna caps ccache cdda cddb cdio cdparanoia cdr cdrom chroot cjk cle266 cli colordiff cpudetection cracklib crypt css cups curl curlwrappers d dba dbase dbus dga directfb dosformat dri droproot dv dvd dvdread ecc edl elf emacs emboss emf encode ethereal evo fam fb fbcon fbdev fbsplash ffmpeg fftw firefox flac flash fltk font-server foomaticdb fortran freewnn ftp fuse gcc-libffi gcj gcl gd gdbm geldkarte geoip gif gimp ginac gnuplot gpm graphviz gs gstreamer gtk h323 hal http httpd iconv icq id3 idea imagemagick imap imlib irc isdnlog jabber jack jackmidi java javascript jce jikes john joystick jp2 jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility kdexdeltas kexi kqemu ladspa lame langpacks latex lha libcaca libgda live lm_sensors logitech-mouse logrotate lzo lzw lzw-tiff m17n-lib mad maildir math matroska mbrola memlimit midi mikmod mime mjpeg mmap mmx mmxext mng mod mono moznocompose moznoirc moznomail mozsvg mp3 mp4live mpeg mpeg2 mpeg4 mpi mplayer msdav mudflap mule multiuser musepack music mysqli ncurses net network nls nptl nptlonly nsplugin ntfs ntlm nvidia objc octave odbc offensive ogg oggvorbis ogre on-the-fly-crypt opengl openmp oscar oss pam pascal patented pcre pda pdf pdfkit perl php plotutils png posix povray ppds pppd print python qt3 qt3support qt4 quicktime rar rdesktop readline real reflection reiserfs samba scenarios screen sdl sensord session sftp sid slang slp smartcard smime sndfile soap sockets softmmu speex spell spl sql sqlite ssl stream subp subtitles subversion svg svga svgz swat sysfs syslog tcl tcltk tcpd tetex theora tidy tiff timidity tk tordns tos transcode truetype truetype-fonts type1 type1-fonts unicode usb usepackagedmakefiles userlocales utempter v4l v4l2 vcd vidix visualization vlm vnc vorbis vst webdav win32codecs wma wma123 wmf wv wxgtk1 wxwindows x264 x86 xanim xchatdccserver xchatnogtk xchattext xemacs xine xinerama xml xorg xpm xprint xscreensaver xv xvid xvmc yv12 zip zlib" ALSA_CARDS="cs46xx ens1371" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev joystick" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="nvidia nv" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
*** Bug 193052 has been marked as a duplicate of this bug. ***
*** Bug 193950 has been marked as a duplicate of this bug. ***
*** Bug 194394 has been marked as a duplicate of this bug. ***
*** Bug 196388 has been marked as a duplicate of this bug. ***
This thing is a real PITA... Let's try again.
Created an attachment (id=135078) [edit] scons-0.97.ebuild.diff Bunch of other attempts to try to get scons behave. Python folks, please review and commit. Ideally, revbump and keep the keywords so that we can see if it helped or not.
Created an attachment (id=135080) [edit] scons-0.97.ebuild.diff Since ColdWind says he's still got stale junk left on filesystem, let's drop the has_version stuff altogether.
*** Bug 198039 has been marked as a duplicate of this bug. ***
*** Bug 199203 has been marked as a duplicate of this bug. ***
Jakub, I am no "python-guy", but looking at your patch, I wonder if it the "${D}" is really what you want. On my system, this tries to delete .py[co] files in /var/tmp/portage/<snip>/image/usr/lib/scons-0.97/SCons whereas the old bytecodes still reside in /usr/lib/scons-0.97/SCons Without ${D} those would have been deleted. Unfortunately, this did not solve _my_ problem (which seems unrelated), so I cannot test if this makes any difference.
(In reply to comment #44) > I am no "python-guy", but looking at your patch, I wonder if it the "${D}" is > really what you want. Yeah, it's definitely what I want. And the stale crap issue you mentioned is handled elsewhere, namely: [[ -d "${ROOT}/usr/$(get_libdir)/scons" ]] \ && rm -rf "${ROOT}/usr/$(get_libdir)/scons"
Plus: rm -f ${ROOT}/usr/$(get_libdir)/${P}/SCons/*.py[co] rm -f ${ROOT}/usr/$(get_libdir)/${P}/SCons/*/*.py[co] Please read the patch more carefully.
I think this problem _may_ be due to scons compiled with one version of python. Later, a new version of python may have been installed, in which case python tries to recompile the .pyo/.pyc scons files. I got this problem when trying to install ardour-2.2. I had recently upgraded python from 2.4 to 2.5 (~amd64), and at first didn't think much of it, since I had been running python-updater. Could it be that scons is not included in the python-updater runthrough, since it keeps its files in a separate directory from /usr/lib/python2.x/site-packages ? Just a thought.
*** Bug 207616 has been marked as a duplicate of this bug. ***
*** Bug 209694 has been marked as a duplicate of this bug. ***
I just hit this bug on my box trying to rebuild games-arcade/rafkill-1.2.3. I, too, have upgraded from python 2.4 to 2.5. Blowing away all of the SCons .pyc/.pyo files, rebuilding SCons, and then re-installing rafkill solved my problem.
*** Bug 211200 has been marked as a duplicate of this bug. ***
This hit me (again) on x86 while building ardour-2.4[.1], using scons-0.97. A rebuild of scons did not help. By unmerging scons, /usr/lib/scons-0.97 was deleted completely. Emerging a fresh scons afterwards, I was back in business.
*** Bug 220100 has been marked as a duplicate of this bug. ***
*** Bug 225063 has been marked as a duplicate of this bug. ***
Had this problem with sci-calculators/abakus-0.91, removing scons and reinstalling it worked. This is with paludis-0.26.2.
Hello, I have upgraded from python2.4 to python2.5 recently but I didn't have scons installed previously. I installed scons and I haven't had any problems whatsoever. Best regards,
Reading all posts in here and after testing a lot, here's what I got Indeed, python-updater doesn't care about SCons so when executed, it won't update scons to use the newer Python version. When SCons is re-emerged, all .pyc and .pyo files created by the 'old' SCons remain the same. When SCons is executed for the first time (after the re-emerge), it realizes that all of those files (.pyc and .pyo) are not his, so it tries to remove those files with the misfortune that the removal occurs inside an ebuild raising a sandbox violation. The fix is simple enough, it was already in the ebuild but it just doesn't get applied correctly because it was a fix for a specific version (say scons-0.96.92-r1) This wrong behavior should occur only when SCons is reinstalled and not when downgrading or upgrading, because all SCons packages create a directory with package name and version in /usr/lib. I'll attach a patch for the ebuild that should work in all versions of SCons and is based on Jakub's solution in #46. The thing missing here is how to make python-updater scons aware, but that should be on a different bug. Best regards,
Created an attachment (id=160237) [edit] Patch for sandbox violations in scons-0.97.ebuild As I said, this should work for all versions of scons.
Try to unmerge scons and emerge it again sudo emerge -av --unmerge scons sudo emerge -av -1 scons
Hello, Fixed scons-0.97 and added scons-1.0.0 to CVS. Closing bug now. Regards,
Can you please make a version bump to 0.97-r1 for getting this? I have suffered this problem until I manually rebuilt scons, I think that other users would prefer not need to manually do this for fixing these access violations, also, this is not simply a scons' compile failure, then, I think that a version bump (and its stabilization in future) would be highly appreciated Thanks a lot :-)
*** Bug 236655 has been marked as a duplicate of this bug. ***
(In reply to comment #61) > Can you please make a version bump to 0.97-r1 for getting this? > > I have suffered this problem until I manually rebuilt scons, I think that other > users would prefer not need to manually do this for fixing these access > violations, also, this is not simply a scons' compile failure, then, I think > that a version bump (and its stabilization in future) would be highly > appreciated > > Thanks a lot :-) > Hello Pacho, Scons-1.0.0 is already in the tree, which is the latest release of scons. Installing this doesn't solve your problem? Any particular reason why you need 0.97 specifically? Thanks, Best regards,
I am using 0.97 because it's in stable tree and I thought that would be easier make a version bump to -r1 and stabilize it immediatly while 1.0.0 will require wait until 19 Sep for stabilizing it This would really fix this issue for most of people using stable tree :-)
