Just a small request to bump ntp and the new initscripts to x86, they've been in testing for quite a long time now.
pappy: we need hardened support in 4.1.2 also if i'm to mark this stable
SpanKY Does ntp fail currenty with asm BREG or relocation problems? If so then its not fPIC aware. Best I can tell is has no such problems. ------------- pappy I just rebuilt mine and it looks all good here. /usr/bin/ntpd: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
i can compile ntp-4.1.2 with these CFLAGS: -march=pentium4 -O2 -frename-registers -fomit-frame-pointer -pipe -mfpmath=sse -mmmx -msse -msse2 -fdelete-null-pointer-checks -funroll-loops -ffast-math -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE BREG errors are related to fPIC ? as in fPIC should be enabled or as in it should be disabled ? and if thats the only question you have before moving 4.1.2 to stable and adding hardened support, go right ahead and do so ;)
Q: BREG errors are related to fPIC ? as in fPIC should be enabled or as in it should be disabled ? A: As it it should be disabled via inherit flag-o-matic filter-flags -fPIC In any problematic ebuilds that show up with these types of problems, sometimes we can work around them in other more creative ways. emit position-independent code, suitable for dynamic linking is a major plus for users of PaX/grsec when ASLR is enabled ---------------------------- I'm not sure what arch your having fPIC problems with ntp on. I've rebuilt mine here local (x86, ~x86) with about every combo of CFLAGS I could think of, over here it compiles and links fine with hgcc-2.2.2 enabled and -fPIC, -fstack-protector in and out of my CFLAGS. CFLAGS="-mcpu=i686 -O3 -pipe" and with hgcc which transparently enables the equiv of CFLAGS="-mcpu=i686 -O3 -pipe -fPIC -fstack-protector" On a non stripped binary we can use this to see of propolice was compiled in. solar@simple solar $ nm `which ntpd` | grep __guard 0004f580 d __guard 0003feb0 t __guard_setup -- Then we check our linkage table and it all looks good. Only thing I could remotely see you having problems with at this point would be linking to (-lcap libcap.so.1) which I think might not be fPIC aware code. solar@simple solar $ ldd `which ntpd` libm.so.6 => /lib/libm.so.6 (0x2b4a7000) libcap.so.1 => /lib/libcap.so.1 (0x2b4c9000) libreadline.so.4 => /lib/libreadline.so.4 (0x2b4cc000) libelf.so.1 => /usr/lib/libelf.so.1 (0x2b4f9000) libc.so.6 => /lib/libc.so.6 (0x2b50b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2b47f000) # little test to confirm it works. simple root # ntpdate ntp.nasa.gov 24 Sep 10:46:09 ntpdate[28492]: adjust time server 198.123.30.132 offset 0.000046 sec ------ So as it sits right now I see no reason not to move this ntp-4.1.2 to stable without any changes or checks for hgcc, fPIC , fstack-protector. Btw I'm using this software set for everything. [ebuild R ] sys-devel/binutils-2.14.90.0.6-r3 +nls -bootstrap -build [ebuild R ] sys-devel/gcc-3.2.3-r2 -static +nls -bootstrap -java -build [ebuild R ] sys-libs/glibc-2.3.2-r1 +nls -pic -build -nptl [ebuild U ] sys-devel/hardened-gcc-2.3.2 [2.2.2]
http://www.gentoo.org/cgi-bin/viewcvs.cgi/net-misc/ntp/ntp-4.1.1b-r6.ebuild.diff?r1=1.5&r2=1.6 so that diff does not need to be added to 4.1.2 ?
Well from all my testing here I would say no its not needed anymore. hardened-gcc is a ~arch package and will remain that way for some time so I think it should not prevent a package from going stable. pappy any comments on your bug here?
ppc and x86 is now stable sparc, can you make ntp-4.1.2 stable ?
We need to fix bug #260620 first.
Bug #260620 does not exist.
ntp-4.1.2 just failed/blew up on sparc64 using gcc-2.95.3 --------------------------------------------------------- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../librsaref -mcpu=v9 -mtune=v9 -O3 -pipe -fomit-frame-pointer -fPIC -Wall -Wcast-qual -Wmissing-prototypes -Wshadow -Wstrict-prototypes -pipe -MT ntpd.o -MD -MP -MF ".deps/ntpd.Tpo" \ -c -o ntpd.o `test -f 'ntpd.c' || echo './'`ntpd.c; \ then mv -f ".deps/ntpd.Tpo" ".deps/ntpd.Po"; \ else rm -f ".deps/ntpd.Tpo"; exit 1; \ fi In file included from ../include/ntp_fp.h:10, from ../include/ntpd.h:6, from ntpd.c:15: /usr/include/netinet/in.h:259: `__u32' redeclared as different kind of symbol /usr/include/asm-sparc/types.h:27: previous declaration of `__u32' /usr/include/netinet/in.h:261: `__u16' redeclared as different kind of symbol /usr/include/asm-sparc/types.h:24: previous declaration of `__u16' ntpd.c:218: warning: no previous prototype for `drop_root' make[2]: *** [ntpd.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/var/tmp/portage/ntp-4.1.2/work/ntp-4.1.2/ntpd' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/ntp-4.1.2/work/ntp-4.1.2' make: *** [all] Error 2 + diefunc src_compile 66 2 + local funcname=src_compile lineno=66 exitcode=2 + shift 3 + echo + echo '!!! ERROR: net-misc/ntp-4.1.2 failed.' !!! ERROR: net-misc/ntp-4.1.2 failed. + echo '!!! Function src_compile, Line 66, Exitcode 2' !!! Function src_compile, Line 66, Exitcode 2 + echo '!!! (no error message)' !!! (no error message) + echo + exit 1
Big-Endian archs will fail on ntp-4.1.2 due to a glibc conflict. Wesolows made a patch for it, which I've added in the linux-headers-2.4.21 ebuild (but not 2.4.19), and in mips-headers-2.4.21. The other big-endian archs, ppc and hppa, I'm not sure if this affects them or not. They need to check to see if it does, and if so, use the patch on Comment #3 on Bug #26062 to fix the issue. Ppc I know uses ppc-headers (I checked their profile), hppa looks to still use linux-headers (despite having an hppa-headers), so if this affects them, they'll need to give the linux-headers-2.4.21 ebuild a run. This glibc issue is fixed upstream in 2.4.23 (check the Changelog), however, 2.4.22 linux-headers + iputils breaks, so it's likely we won't be using 2.4.22+ for quite awhile.
Marked stable on sparc, enjoy!
