I get a sandbox violation when I'm trying to emerge djbdns-1.05-r12 or -r14 These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] net-dns/djbdns-1.05-r14 [1.05-r9] -aliaschain -cnamefix -doc -fwdzone +ipv6 -multipleip -roundrobin -semanticfix 0 kB Total size of downloads: 0 kB Do you want me to merge these packages? [Yes/No] >>> emerge (1 of 1) net-dns/djbdns-1.05-r14 to / >>> md5 src_uri ;-) djbdns-1.05.tar.gz >>> md5 src_uri ;-) djbdns-1.05-test21.diff.bz2 >>> Unpacking source... >>> Unpacking djbdns-1.05.tar.gz to /var/tmp/portage/djbdns-1.05-r14/work >>> Unpacking djbdns-1.05-test21.diff.bz2 to /var/tmp/portage/djbdns-1.05-r14/work * Applying headtail.patch ... [ ok ] * Applying dnsroots.patch ... * A dry-run of patch command succeeded, but actually * applying the patch failed! * Failed Patch: dnsroots.patch! * * Include in your bugreport the contents of: * * /var/tmp/portage/djbdns-1.05-r14/temp/dnsroots.patch-10499.out !!! ERROR: net-dns/djbdns-1.05-r14 failed. !!! Function epatch, Line 402, Exitcode 0 !!! Failed Patch: dnsroots.patch! !!! If you need support, post the topmost build error, NOT this status message. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-net-dns_-_djbdns-1.05-r14-10498.log" rename: /etc/dnsroots.global -------------------------------------------------------------------------------- The reason might be related to the fact that there is an absolute path in the patch itself, and patch -p0 matches /etc/dnsroots.global on the live filesystem *IF* the file is still the one that was distributed with djbdns. I.e., if /etc/dnsroots.global is identical with ${S}/dnsroots.global. In that case, epatch will run patch -p0 first, it will determine /etc/dnsroots.global as patchable and will try to apply the patch with patch -p0. In the general case when /etc/dnsroots.global has been modified, patch -p0 will fail, and patch -p1 will apply against ${S}/dnsroots.global. Solution: Remove the initial "/" from within the patch, add a leading dot or anything to make the path of the files relative.
I tried both emerge =net-dns/djbdns-1.05-r12 and emerge =net-dns/djbdns-1.05-r14 Both emerges worked. Please submit your "emerge info" output. My emerge info was as follows: Portage 2.0.51-r8 (default-linux/amd64/2004.3, gcc-3.4.1, glibc-2.3.4.20041102-r 0, 2.6.9-gentoo-r4 x86_64) ================================================================= System uname: 2.6.9-gentoo-r4 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.7 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Aug 18 2004, 08:54:07)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.8.5-r2, 1.6.3, 1.7.9, 1.9.3, 1.4_p6 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.2-r7 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O2 -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/s hare/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/gentoo-x86/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache distlocks sandbox" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo ftp:/ /gentoo.ccccom.com http://gentoo.ccccom.com http://mirror.datapipe.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/gentoo-x86/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/gentoo-x86" PORTDIR_OVERLAY="" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="amd64 X acpi alsa apache2 berkdb bitmap-fonts cdr crypt curl esd f77 fam fl ac flash gd gdbm gif gmp gnome gnomedb gnutls gpm gstreamer gtk imap imlib ipv6 jp2 jpeg justify ldap libwww lzw lzw-tiff mad mcal mikmod mozilla multilib ncurs es nntp oggvorbis opengl oss pam pdflib png postgres readline samba slang snmp s sl tcpd threads tiff truetype usb userlocales xinerama xml xml2 xmms xpm xrandr xv xvid zlib"
I may have not been clear the first time. My problem was that the version of /etc/dnsroots.global that I had on my live filesystem was a totally unpatched one. In other words, the version of dnsroots.global on my live filesystem was identical to the one that is in the original djbdns sources. This is where the absolute path in the patch itself causes a problem. I already covered this in the last two paragraphs of my original comment. Please refer to them for further information.
I just rm'd my /etc/dnsroots.global Then I untarred the orginal djbdns-1.05.tar.gz file and copied its /etc/dnsroots.global file to /etc. I then ran USE="-*" energe djbdns I then ran etc-update which informed me that a new copy of /etc/dnsroots.global was available. I allowed etc-update to overwrite my old one. I see nothing in this scenario that does not work. What problem are you experiencing? Show specific examples, using ls -l, md5sum, what cmds you are typing, etc.
I now checked the CVS and I see that you fixed the patch to use relative paths on the 18th of December. As I look at the comments to this bug it probably went like this: 1. I report the bug in November. 2. You fix it on your machine on Dec.18. 3. You report that it works for you on the same day. 4. I read your response and report that it couldn't possibly just magically work, because there is a problem that needed fixing. So, you did indeed fix the problem (probably in no connection with this bug), but I didn't know about it, hence Comment #2. Marking CLOSED.
Ooops, it's not NEEDINFO. Have to reopen and close again.
.
