emacs-cvs tries to disable the sandbox by setting SANDBOX_DISABLED="1" in the global scope. The way it does this isn't supported anymore according to #gentoo-portage: "<@ferringb> marienz: file a bug please, telling them to stick that god awful hack in src_compile...". adding 'export SANDBOX_ON="0"' to the top of src_compile makes it compile again. This is not a problem for people without portage-cvs, but I think it won't hurt to add this already, as portage-cvs will eventually become "normal" portage. According to ferringb SANDBOX_ON will keep working. Reproducible: Always Steps to Reproduce: 1. emerge portage-cvs and sandbox from dev.gentoo.org/~ferringb 2. emerge emacs-cvs 3. watch bootstrap-emacs segfault. Actual Results: the bootstrap-emacs segfaulted and the compile failed, FEATURES="-sandbox -usersandbox" made the emerge work. Expected Results: merged emacs-cvs Portage 20041207 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9-gentoo-r12-m1 i686) ================================================================= System uname: 2.6.9-gentoo-r12-m1 i686 AMD Athlon(tm) XP 2600+ Gentoo Base System version 1.6.8 distcc: No such file or directory [disabled] Autoconf: sys-devel/autoconf-2.59-r6,sys-devel/autoconf-2.13 Automake: sys-devel/automake-1.8.5-r2,sys-devel/automake-1.5,sys-devel/automake- 1.4_p6,sys-devel/automake-1.6.3,sys-devel/automake-1.7.9,sys-devel/automake-1.9. 3 Binutils: sys-devel/binutils-2.15.92.0.2-r2 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.10-r2 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Dec 19 2004, 00:40:25)] ACCEPT_KEYWORDS="x86 ~x86" CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer -fweb -frename-registers " CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer -fweb -frename-registers" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig candy ccache confcache distlocks noauto prelink sandbox sfperms userpriv usersandbox verify-rdepend" GENTOO_MIRRORS="http://ftp.easynet.nl/mirror/gentoo/ http://www.gigaload.org/gentoo.org/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.nl.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex X alsa ansi apm avi bitmap-fonts cdr crypt dga edl emacs faad fbcon flac foomaticdb fortran gnome gstreamer gtk2 imagemagick javascript jit jpeg libcaca libwww maildir md5sum mikmod mmx mmx2 mng mozdevelop mozsvg mpeg ncurses nethack network nls nntp no-old-linux no_wxgtk1 nptl nptlonly oggvorbis pam png python qemu-fast quicktime readline real rtc softmmu spell sse ssl svg tetex truetype truetype-fonts unicode userlocales xml2 xv zlib"
Get that sandbox disabling out of the global scope before I give you all wedgies. You do realize that portage has to source that ebuild just to get the metadata out of it, and *any* mistake in the ebuild is no longer sandbox'd during the depends phase, right? It's massively wrong, shift it to the phase you need it in, and leave it there.
Do the same for app-editors/emacs while you're at it.
And... app-emacs/erc-cvs app-emacs/gnu-cvs app-editors/xemacs-gtk app-editors/xemacs
So, one year is gone, nothing changed. :( emacs herd, please get that crap out of the global scope *now*. As for xemacs, it's probably for QA to fix, that herd is purely virtual.
I have commented out the SANDBOX disabling #SANDBOX_DISABLED="1" in the emacs ebuild emacs emerge and works fine here.
Dear QA, while there are tons of bugs being filed for minor/cosmetic QA issues currently, I'd expect kinda more activity on a pretty serious QA violation, such as this one. This bug has been open for 14 months now and affects multiple ebuilds, yet the maintainer doesn't seem to care at all? So - any action here?
Dear Jakub, why don't you provide a patch along with a proof that it works for all affected packages? As far as I know, no-one in QA is sufficiently familiar with emacs to be able to do this with any confidence of it actually working.
(In reply to comment #7) > Dear Jakub, why don't you provide a patch along with a proof that it works for > all affected packages? As far as I know, no-one in QA is sufficiently familiar > with emacs to be able to do this with any confidence of it actually working. The solution has been mentioned directly in the original bugreport 1+ year ago. This bug is about sandbox being disabled in *global scope*. So the *interim* solution is moving that to src_compile() at least, which I'm pretty sure is something that you or any other competent QA team member can do without any problems. While the real solution obviously is making emacs compile correctly with sandbox enabled (some people actually confirmed above that it works just fine), that is *not* QA's task nor it is the topic of this bug. This bug is about a gross QA violation, that hasn't been dealt with for 14 months by the maintainer. But of course I understand that some of the QA members might be busy filing bugs on other urgent issues, like a potentially conflicting digest in a binary-only commercial ebuild that noone has ever complained about... No offense meant, but I'd say you need to get your priorities right here.
(In reply to comment #8) > The solution has been mentioned directly in the original bugreport 1+ year ago. > This bug is about sandbox being disabled in *global scope*. So the *interim* > solution is moving that to src_compile() at least, which I'm pretty sure is > something that you or any other competent QA team member can do without any > problems. Where is your proof that this works? If you can show that it is only required in src_compile in all instances then someone will go ahead and do that. Otherwise, all changing it will do is get a bug closed without fixing the problem. > While the real solution obviously is making emacs compile correctly with > sandbox enabled (some people actually confirmed above that it works just fine), No. We need confirmation for every affected package across multiple systems before we're touching this. > that is *not* QA's task nor it is the topic of this bug. This bug is about a > gross QA violation, that hasn't been dealt with for 14 months by the > maintainer. But of course I understand that some of the QA members might be > busy filing bugs on other urgent issues, like a potentially conflicting digest > in a binary-only commercial ebuild that noone has ever complained about... No > offense meant, but I'd say you need to get your priorities right here. Priority goes first and foremost to stuff that's fixable. There's no point wasting hours on something we can't change. If you want this fixed, you're more than welcome to do the work behind it. Then, and only then, can someone from QA apply the fix for you.
I created app-editors/emacs-21.4-r2.ebuild from app-editors/emacs-21.4-r1 and moved SANDBOX_DISABLED=1 from global scope to SANDBOX_ON=0 in src_compile(). Since I don't touch stablized ebuilds, arch testers are needed to take emacs-21.4-r2.ebuild which has unstable keywords, test it and then stablize it. Then emacs-21.4-r1.ebuild can be removed and this bug can be resolved. I fixed emacs-18.59.ebuild and emacs-22.0.50.ebuild also.
Re: Comment #5: I might work for you since it is an intermittent problem.
Fixed app-emacs/erc-cvs
Fixed app-emacs/gnus-cvs
Emacs done on IA64 -- compiles and works fine here. Thanks for the heads-up.
Marked app-editors/emacs-21.4-r2 stable on hppa. The status of app-editors/xemacs wrt this bug is unclear. If something needs to be done after all (which version to mark?), please re-add hppa@ to the CC list.
stable on ppc64
Marked ppc stable. If xemacs needs to be marked as well, please add us again.
emacs-21.4-r3 is now stable for x86. Now I'll have a look at the other packages mentioned here.
Looks like x86 is done here. Please re-add us if necessary.
emacs-21.4-r3 stable on amd64. not sure if I'm supposed to keyword anything else, please readd amd64 if so.
Keep on SPARC'in
I tested emacs-21.4-r3 on alpha. I emerge'd it serveral times with different combinations of USE flags and did not get any sandbox violations. I also tested the application itself and didn't run into any problems. Can someone from the alpha team mark this as stable? # emerge --info Portage 2.1_pre5-r4 (default-linux/alpha/no-nptl/2.4, gcc-3.4.4, glibc-2.3.5-r3, 2.4.32 alpha) ================================================================= System uname: 2.4.32 alpha EV56 Gentoo Base System version 1.12.0_pre16 dev-lang/python: 2.3.5, 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.4.26-r1 ACCEPT_KEYWORDS="alpha ~alpha" AUTOCLEAN="yes" CBUILD="alpha-unknown-linux-gnu" CFLAGS="-mieee -pipe -O2 -mcpu=ev56" CHOST="alpha-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mieee -pipe -O2 -mcpu=ev56" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig collision-protect distlocks maketest sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://adelie.polymtl.ca/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://www.gtlib.gatech.edu/pub/gentoo http://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ http://gentoo.seren.com/gentoo http://gentoo.chem.wisc.edu/gentoo/ http://cudlug.cudenver.edu/gentoo/ http://gentoo.mirrors.pair.com/ http://gentoo.mirrors.tds.net/gentoo http://gentoo.netnitco.net http://mirror.espri.arizona.edu/gentoo/ http://mirrors.acm.cs.rpi.edu/gentoo/ http://gentoo.arcticnetwork.ca/ http://open-systems.ufl.edu/mirrors/gentoo http://gentoo.llarian.net/ http://gentoo.binarycompass.org http://gentoo.mirrored.ca/ http://mirror.datapipe.net/gentoo http://gentoo.cs.lewisu.edu/gentoo/ http://prometheus.cs.wmich.edu/gentoo http://modzer0.cs.uaf.edu/public/gentoo/ http://mirror.usu.edu/mirrors/gentoo/ http://mirror.phy.olemiss.edu/mirror/gentoo http://mirror.mcs.anl.gov/pub/gentoo/ http://gentoo.mirrors.easynews.com/linux/gentoo/ http://gentoo.cites.uiuc.edu/pub/gentoo/ http://mirror.clarkson.edu/pub/distributions/gentoo/ http://cdot.senecac.on.ca/software/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="alpha X aac aalib aim alsa apache2 artworkextra async audacious audiofile bash-completion berkdb binfilter bitmap-fonts bittorrent bl bonjour c++ cairo calendar cdinstall cdparanoia cdr cdrom chroot cli config_wizard cracklib crypt cscope csv ctype cups curl curlwrappers cvs cvsgraph dhcp dillo dri editor eds elf encode epiphany escreen esd ethereal extraicons extras ffmpeg fftw figlet firefox flac ftp gdb gdbm gif glep gnome gnutls gpm grammar gsl gstreamer gtalk gtk gtk2 gtkspell gvim gzip html icq id3 imlib ipod ipv6 jabber javascript jpeg justify ladspa lame libg++ libsexy libwww lite lj logrotate lua mad mapeditor md5sum mikmod motif moznoirc moznomail moznoroaming mozsha1 mp3 mpeg mpeg2 mplayer msn msnextras music ncurses net nethack nls offensive ogg oggvorbis opengl openssh openssl oscar oss pam pdflib perl png python quicktime quotes readline real recode reiserfs scp screen sdl sftp skins sndfile sockets sounds sox speech spell ssl subversion symlink syslog tcpd threads truetype truetype-fonts type1-fonts udev userlocales vcd videos vim vim-with-x vorbis wma wma123 xml xml2 xmlreader xmms xv xvid yahoo zip zlib elibc_glibc kernel_linux userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LDFLAGS, LINGUAS
Alpha done, thanks Thomas.
Looks like this is all done.
