" XORP is the eXtensible Open Router Platform. Our goal is to develop an open source software router platform that is stable and fully featured enough for production use, and flexible and extensible enough to enable network research. Currently XORP implements routing protocols for IPv4 and IPv6 and a unified means to configure them. In future, we would also like to support custom hardware and software forwarding architectures. XORP is free. It is covered by a BSD-style license and is publicly available for research, development, and use. " Reproducible: Always Steps to Reproduce:
Created attachment 35915 [details] Ebuild not finished, it got certains problems to fix before using it Hi all! I've made an ebuild for it and I've tested it. It seems to be working, but I get many ACCESS DENIED message by portage. They don't seem important since it's in the post-compilation checks, but they are quite annoying and there surely is a better way to handle the post-compilation checks but I don't know it. If someones knows it, please correct it!
Created attachment 37493 [details] xorp-1.0.ebuild This should work just fine. I dont think the post-compilation checks are necessary.
Jay, interested?
Sure, what the heck... :)
1.1 was released
I'm taking over this...
Been working abit on this, got it to compile and install, but still haven't managed to fully make the beast go. if anyone care to try in the meanwhile, the ebuild is here: http://dev.gentoo.org/~eldad/xorp/
Just to let you know that I had a compile/install problem that was only resolved by upgrading to http://xorp.org/releases/1.2-RC/xorp-1.2-RC.tar.gz This releases has worked fine for me at the moment. (I wish I'd known about xorp earlier!)
1.2 Released.
Calum: have you used the ebuild to merge it and get a fully running service?
sorry guys, I have no time to take care of this, I'll put it back to maintainer-wanted...
This is now in the sunrise overlay. You can find it at: http://gentoo-sunrise.org/svn/reviewed/net-misc/xorp
Created attachment 93958 [details] xorp-1.2.ebuild
Created attachment 143738 [details] Ebuild for New Version, doesn't work in amd64 I've edited 1.2 ebuild with the new version of the package and need it running in amd64, but it gives me make error... Don't know if same case in x86...
Thanks for the ebuild, maybe you can do one for 1.5 now ;-) One problem though: I don't have the snmp USE flag set, still the compilation seems to want something from the net-snmp package. Probably an upstream issue?
Created attachment 186230 [details] xorp-1.6.ebuild This is a version bump. There are serious sandbox issues. I've taken a look at the test harness and that appears to be OK. I believe the issues are occurring during make install.
(In reply to comment #16) > Created an attachment (id=186230) [edit] > Xorp ebuild 1.6 > > This is a version bump. There are serious sandbox issues. I've taken a look > at the test harness and that appears to be OK. I believe the issues are > occurring during make install. > checking for snmpd... /usr/sbin/snmpd checking if snmpd can be started... ACCESS DENIED open_wr: /usr/share/snmp/mibs/.index ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf ACCESS DENIED open_wr: /var/lib/net-snmp/snmpd.conf yes Some of the failure appears to be in the autoconf. It wants to START snmpd.
(In reply to comment #15) > Thanks for the ebuild, maybe you can do one for 1.5 now ;-) > One problem though: I don't have the snmp USE flag set, still the compilation > seems to want something from the net-snmp package. Probably an upstream issue? > I seem to agree, not quite sure why we want a 1.5, though I can whip one up and see what breaks.
(In reply to comment #18) > (In reply to comment #15) > > Thanks for the ebuild, maybe you can do one for 1.5 now ;-) > > One problem though: I don't have the snmp USE flag set, still the compilation > > seems to want something from the net-snmp package. Probably an upstream issue? > > > > I seem to agree, not quite sure why we want a 1.5, though I can whip one up and > see what breaks. > Glad I did, the same issue exists in 1.5
If you force -SNMP, it will break as follows: checking if snmpd can be started... skipped configure: error: XORP MIBs will not be built configure: error: ./configure failed for mibs This is either an upstream bug, or the thing simply requires SNMP.
The xorp-1.8.5 has released, would some nice fellow bump it up? And source of xorp-1.6 has moved to: http://www.xorp.org/releases/old/xorp-1.6.tar.gz instead of: http://www.xorp.org/releases/xorp-1.6.tar.gz
Created attachment 386398 [details] Build.log Portage 2.2.14_rc1 (python 2.7.8-final-0, default/linux/amd64/13.0, gcc-4.9.1, glibc-2.19-r1, 3.11.1 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.11.1-x86_64-Intel-R-_Core-TM-2_Duo_CPU_E4600_@_2.40GHz-with-gentoo-2.2 KiB Mem: 2047648 total, 570012 free KiB Swap: 2097148 total, 2078072 free Timestamp of tree: Thu, 09 Oct 2014 21:30:01 +0000 ld GNU ld (Gentoo 2.24 p1.4) 2.24 ccache version 3.1.9 [disabled] app-shells/bash: 4.2_p53 dev-lang/perl: 5.20.1 dev-lang/python: 2.7.8, 3.4.1 dev-util/ccache: 3.1.9-r3 dev-util/pkgconfig: 0.28-r2 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.13.1 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.14.1 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.9.1 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2-r1 sys-devel/make: 4.1 sys-kernel/linux-headers: 3.16 (virtual/os-headers) sys-libs/glibc: 2.19-r1 Repositories: gentoo roslin sunrise ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -mno-sse3 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=nocona -mno-sse3 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://gentoo.mirror.pw.edu.pl/" LANG="pl_PL.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/roslin /var/lib/layman/sunrise" USE="amd64 mmx openmp openssl readline sse sse2 ssl threads udev unicode" ABI_X86="64" ELIBC="glibc" KERNEL="linux" PYTHON_SINGLE_TARGET="python3_4" PYTHON_TARGETS="python2_7 python3_4" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON [ebuild N ] net-analyzer/traceroute-2.0.20 USE="-static" [ebuild N ] dev-util/scons-2.3.2 USE="-doc" PYTHON_TARGETS="python2_7" [ebuild N ] net-misc/xorp-1.8.5 USE="-snmp"
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
