Re: Preparation for creating netbsd-7 branch
On Jul 20, 3:50am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: Preparation for creating netbsd-7 branch | christos@ wrote: | | In article 140719232527.m0121...@mirage.ceres.dti.ne.jp, | Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote: | On behalf of the release engineering team, I am happy to announce that | the release process for NetBSD 7.0 is now underway. | | Does anyone (core? releng?) has a particular plan about | the default MACHINE_ARCH for each arm ports? | | Let's discuss it. What do you propose? | | I asked matt@ on port-arm last year and got no answer. | http://mail-index.netbsd.org/port-arm/2013/10/26/msg002073.html | I think (other) Core members should handle it. Yes, I've been trying to follow that thread. Can you please summarize the problem and propose a solution? Is it a backwards compatibility issue? Or do we need to worry about binaries produced with sf on hf able machines in the future? Why would one do that? To be compatible with old machines? christos
Re: Preparation for creating netbsd-7 branch
christos@ wrote: On Jul 20, 3:50am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: Preparation for creating netbsd-7 branch | christos@ wrote: | | In article 140719232527.m0121...@mirage.ceres.dti.ne.jp, | Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote: | On behalf of the release engineering team, I am happy to announce that | the release process for NetBSD 7.0 is now underway. | | Does anyone (core? releng?) has a particular plan about | the default MACHINE_ARCH for each arm ports? | | Let's discuss it. What do you propose? | | I asked matt@ on port-arm last year and got no answer. | http://mail-index.netbsd.org/port-arm/2013/10/26/msg002073.html | I think (other) Core members should handle it. Yes, I've been trying to follow that thread. Can you please summarize the problem and propose a solution? Is it a backwards compatibility issue? Or do we need to worry about binaries produced with sf on hf able machines in the future? Why would one do that? To be compatible with old machines? The main problem is lack of design description with random changes. http://mail-index.netbsd.org/port-arm/2013/10/26/msg002069.html http://mail-index.netbsd.org/port-arm/2013/10/27/msg002075.html Without specification, no idea what is intentional and what is broken. Anyway, most concerns are too late to discuss. - MACHINE_ARCH should be static or dynamic - how sysctl hw.machine_arch should be handled - different MACHINE_ARCH for kernel and userland should be allowed or not - different MACHINE_ARCH should be used for armv4/v6/v7 or not - a single kernel should handle different MACHINE_ARCH userland or not - should we use different MACHINE_ARCH for softfloat and hardfloat or not All of these usages have been changed from other MACHINE_ARCH. For the next release, core/releng should decide per current implementation: - how the default userland MACHINE_ARCH should be deteremined - how to handle migration from old ABI to new one on sysinst - which MACHINE_ARCH binaries should be prepared for official packages etc. for the new MACHINE_ARCH strategies. --- Izumi Tsutsui
EuroBSDCon 2014 in Sofia
Registration[1] is now open for this years EuroBSDCon in Sofia, Sep 25 - 28. The program[2] features lots of NetBSD content, and other great talks as well - I hope this will be a fantastic conference. Looking forward to seeing you all in Sofia, Martin [1] http://2014.eurobsdcon.org/talks-and-schedule/ [2] http://2014.eurobsdcon.org/registration/
6.99.44 - 6.99.47 upgrade broke c++ binary compatibility
Hi! After upgrading kernel + userland from 6.99.44 (from around June 20) to 6.99.47 (from last night) without reinstalling pkgsrc packages yet, at least two pkgsrc programs don't work any longer. libreoffice: # soffice javaPathHelper: not found terminate called after throwing an instance of 'com::sun::star::lang::IllegalArgumentException' terminate called recursively # (ignore the javaPathHelper line, that's always there) geeqie: # geeqie terminate called after throwing an instance of 'Exiv2::BasicErrorchar' terminate called recursively zsh: abort (core dumped) geeqie The 'throwing' messages make me think of C++. Any ideas what broke this, or how this could be fixed? Thomas
Re: 6.99.44 - 6.99.47 upgrade broke c++ binary compatibility
On Sun, 20 Jul 2014, Thomas Klausner wrote: Hi! After upgrading kernel + userland from 6.99.44 (from around June 20) to 6.99.47 (from last night) without reinstalling pkgsrc packages yet, at least two pkgsrc programs don't work any longer. libreoffice: # soffice javaPathHelper: not found terminate called after throwing an instance of 'com::sun::star::lang::IllegalArgumentException' terminate called recursively # Hmmm. I upgraded to 6.99.47 just last week, and then rebuild all of my packages. The newly-rebuilt libreoffice works fine (I don't have a copy of the old package any more). # soffice javaPathHelper: not found javaldx: Could not find a Java Runtime Environment! Warning: failed to read path from javaldx LibreOffice intializtion progress screen is displayed, followed by the main window - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: 6.99.44 - 6.99.47 upgrade broke c++ binary compatibility
On Sun, Jul 20, 2014 at 10:15:29AM -0700, Paul Goyette wrote: Hmmm. I upgraded to 6.99.47 just last week, and then rebuild all of my packages. The newly-rebuilt libreoffice works fine (I don't have a copy of the old package any more). I hope so. My point was that the old binary doesn't work any longer, but NetBSD supposedly cares about binary compatibility and it should still work. Thomas
Re: 6.99.44 - 6.99.47 upgrade broke c++ binary compatibility
On Sun, Jul 20, 2014 at 07:11:16PM +0200, Thomas Klausner wrote: After upgrading kernel + userland from 6.99.44 (from around June 20) to 6.99.47 (from last night) without reinstalling pkgsrc packages yet, at least two pkgsrc programs don't work any longer. Which architecture and build settings? Joerg
build issue on 6.1.4 amd64
I have mostly been building -current on NetBSD 6.1.3, which has been fine. I tried today on a NetBSD amd64 6.1.4 machine and got the following build failure. I gather this is something to do with stack checking but somewhat unclear how to fix it... # link common-target/genhooks c++ -O -I/home/justin/src/external/gpl3/gcc/usr.bin/common-target/.. -I/home/justin/src/external/gpl3/gcc/usr.bin/backend/obj -I/home/justin/src/external/gpl3/gcc/usr.bin/common-target/../gcc/arch/x86_64 -I. -I/home/justin/src/external/gpl3/gcc/dist/include -I/home/justin/src/external/gpl3/gcc/dist/gcc -DGENERATOR_FILE -o genhooks genhooks.lo errors.lo -L/home/justin/src/obj/tooldir.NetBSD-6.1.4-amd64/lib -lnbcompat /home/justin/src/external/gpl3/gcc/usr.bin/host-libiberty/obj/libiberty/libiberty.a genhooks.lo: In function `emit_findices(char const*, char const*)': genhooks.c:(.text+0x71): undefined reference to `__printf_chk' genhooks.lo: In function `emit_documentation(char const*)': genhooks.c:(.text+0x2fc): undefined reference to `__uflow' genhooks.c:(.text+0x323): undefined reference to `stdout' genhooks.c:(.text+0x335): undefined reference to `__overflow' genhooks.c:(.text+0x395): undefined reference to `__printf_chk' genhooks.c:(.text+0x437): undefined reference to `__printf_chk' genhooks.c:(.text+0x4bf): undefined reference to `__printf_chk' genhooks.c:(.text+0x4f7): undefined reference to `__printf_chk' genhooks.c:(.text+0x510): undefined reference to `__printf_chk' genhooks.lo:genhooks.c:(.text+0x527): more undefined references to `__printf_chk' follow errors.lo: In function `warning(char const*, ...)': errors.c:(.text+0x9a): undefined reference to `stderr' errors.c:(.text+0xa1): undefined reference to `__fprintf_chk' errors.c:(.text+0xb5): undefined reference to `stderr' errors.c:(.text+0xba): undefined reference to `__vfprintf_chk' errors.c:(.text+0xc1): undefined reference to `stderr' errors.c:(.text+0xd5): undefined reference to `__overflow' errors.lo: In function `error(char const*, ...)': errors.c:(.text+0x189): undefined reference to `stderr' errors.c:(.text+0x190): undefined reference to `__fprintf_chk' errors.c:(.text+0x1a4): undefined reference to `stderr' errors.c:(.text+0x1a9): undefined reference to `__vfprintf_chk' errors.c:(.text+0x1b0): undefined reference to `stderr' errors.c:(.text+0x1c4): undefined reference to `__overflow' errors.lo: In function `fatal(char const*, ...)': errors.c:(.text+0x282): undefined reference to `stderr' errors.c:(.text+0x289): undefined reference to `__fprintf_chk' errors.c:(.text+0x29d): undefined reference to `stderr' errors.c:(.text+0x2a2): undefined reference to `__vfprintf_chk' errors.c:(.text+0x2a9): undefined reference to `stderr' errors.c:(.text+0x2bd): undefined reference to `__overflow' errors.lo: In function `internal_error(char const*, ...)': errors.c:(.text+0x372): undefined reference to `stderr' errors.c:(.text+0x379): undefined reference to `__fprintf_chk' errors.c:(.text+0x38d): undefined reference to `stderr' errors.c:(.text+0x392): undefined reference to `__vfprintf_chk' errors.c:(.text+0x399): undefined reference to `stderr' errors.c:(.text+0x3ad): undefined reference to `__overflow' *** Failed target: genhooks
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.NetBSD.org, a NetBSD/amd64 host, using sources from CVS date 2014.07.20.17.56.44. An extract from the build.sh output follows: /tmp/bracket/build/2014.07.20.17.56.44-i386/tools/bin/i486--netbsdelf-install -U -M /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/METALOG -D /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir -h sha256 -N /tmp/bracket/build/2014.07.20.17.56.44-i386/src/etc -c -r -o root -g wheel -m 444 mandoc_mdoc.html7 /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/usr/share/man/html7/mandoc_mdoc.html --- install-libpcap --- --- /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/usr/share/man/html3/pcap_inject.html --- --- install-usr.bin --- --- /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/usr/share/man/man1/pmc.1 --- --- install-crypto/external --- echo '# ' install /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/usr/share/man/man3/krb5_get_init_creds_opt_set_addressless.3; echo /tmp/bracket/build/2014.07.20.17.56.44-i386/tools/bin/i486--netbsdelf-install -U -M /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/METALOG -D /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir -h sha256 -N /tmp/bracket/build/2014.07.20.17.56.44-i386/src/etc -l h -r -o root -g wheel -m 444 /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/usr/share/man/man3/krb5_get_init_creds.3 /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/usr/share/man/man3/krb5_get_init_creds_opt_set_addressless.3 /tmp/bracket/build/2014.07.20.17.56.44-i386/tools/bin/i486--netbsdelf-install -U -M /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/METALOG -D /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir -h sha256 -N /tmp/bracket/build/2014.07.20.17.56.44-i386/src/etc -l h -r -o root -g wheel -m 444 /tmp/bracket/build/2014.07.20.17.56.44 -i386/destdir/usr/share/man/man3/krb5_get_init_creds.3 /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/usr/share/man/man3/krb5_get_init_creds_opt_set_addressless.3 --- install-external --- --- install-mdocml --- --- /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/usr/share/man/html7/mandoc_roff.html --- --- install-crypto/external --- # install /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/usr/share/man/man3/krb5_get_init_creds_opt_set_addressless.3 --- install-sys --- --- install-bootxx_msdos --- --- install-external --- --- install-ibm-public --- --- install-crypto/external --- /tmp/bracket/build/2014.07.20.17.56.44-i386/tools/bin/i486--netbsdelf-install -U -M /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/METALOG -D /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir -h sha256 -N /tmp/bracket/build/2014.07.20.17.56.44-i386/src/etc -l h -r -o root -g wheel -m 444 /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/usr/share/man/man3/krb5_get_init_creds.3 /tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/usr/share/man/man3/krb5_get_init_creds_opt_set_addressless.3 --- install-external --- i486--netbsdelf-install: AAAREADME.html: stat: No such file or directory *** [/tmp/bracket/build/2014.07.20.17.56.44-i386/destdir/usr/share/doc/reference/ref8/postfix/AAAREADME.html] Error code 1 nbmake[9]: stopped in /tmp/bracket/build/2014.07.20.17.56.44-i386/src/external/ibm-public/postfix/share/html 1 error The following commits were made between the last successful build and the failed build: 2014.07.20.15.46.34 uebayasi src/sys/arch/x86/include/intr.h,v 1.45 2014.07.20.15.46.34 uebayasi src/sys/arch/x86/x86/ipi.c,v 1.25 2014.07.20.15.48.54 uebayasi src/sys/arch/x86/x86/ipi.c,v 1.26 2014.07.20.15.58.06 tron src/external/ibm-public/postfix/share/README_FILES/Makefile,v 1.8 2014.07.20.15.58.06 tron src/external/ibm-public/postfix/share/html/Makefile,v 1.9 2014.07.20.15.58.06 tron src/external/ibm-public/postfix/share/readme.mk,v 1.1 2014.07.20.15.58.40 tron src/distrib/sets/lists/misc/mi,v 1.194 2014.07.20.16.04.48 tron src/share/man/man8/wizd.8,v 1.7 2014.07.20.16.40.34 ozaki-r src/sys/net/if_bridge.c,v 1.88 2014.07.20.16.51.29 joerg src/sys/arch/xen/conf/Makefile.xen,v 1.37 2014.07.20.17.56.44 prlw1 src/sys/external/bsd/drm2/include/linux/ctype.h,v 1.2 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2014.07.html#2014.07.20.17.56.44
daily CVS update output
Updating src tree: P src/distrib/sets/lists/base/mi P src/distrib/sets/lists/comp/mi P src/distrib/sets/lists/misc/mi P src/doc/CHANGES P src/etc/etc.macppc/Makefile.inc P src/external/bsd/libc++/dist/libcxxrt/src/dwarf_eh.h U src/external/ibm-public/postfix/share/readme.mk P src/external/ibm-public/postfix/share/README_FILES/Makefile P src/external/ibm-public/postfix/share/html/Makefile P src/external/realtek/urtwn/Makefile U src/external/realtek/urtwn/dist/rtl8188eufw.bin P src/include/search.h P src/lib/libc/stdlib/Makefile.inc P src/lib/libc/stdlib/hcreate.3 P src/lib/libc/stdlib/hcreate.c P src/share/man/man4/urtwn.4 P src/share/man/man8/wizd.8 P src/share/misc/airport P src/sys/arch/algor/conf/P4032 P src/sys/arch/algor/conf/P5064 P src/sys/arch/algor/conf/P6032 P src/sys/arch/algor/conf/files.algor P src/sys/arch/arc/conf/ARCTIC P src/sys/arch/arc/conf/GENERIC P src/sys/arch/arc/conf/M403 P src/sys/arch/arc/conf/MIMORI P src/sys/arch/arc/conf/PICA P src/sys/arch/arc/conf/RPC44 P src/sys/arch/arc/conf/files.arc P src/sys/arch/arm/omap/am335x_prcm.c P src/sys/arch/arm/omap/am335x_prcm.h P src/sys/arch/arm/omap/omap2_reg.h P src/sys/arch/cobalt/conf/GENERIC P src/sys/arch/cobalt/conf/INSTALL P src/sys/arch/cobalt/conf/files.cobalt P src/sys/arch/evbarm/beagle/beagle_machdep.c P src/sys/arch/evbmips/conf/ADM5120 P src/sys/arch/evbmips/conf/ADM5120-NB P src/sys/arch/evbmips/conf/ADM5120-USB P src/sys/arch/evbmips/conf/ALCHEMY P src/sys/arch/evbmips/conf/AP30 P src/sys/arch/evbmips/conf/CPMBR1400 P src/sys/arch/evbmips/conf/DB120 P src/sys/arch/evbmips/conf/GDIUM P src/sys/arch/evbmips/conf/LOONGSON P src/sys/arch/evbmips/conf/MALTA P src/sys/arch/evbmips/conf/MERAKI P src/sys/arch/evbmips/conf/RB153 P src/sys/arch/evbmips/conf/RB433UAH P src/sys/arch/evbmips/conf/WGT624V3 P src/sys/arch/evbmips/conf/XLSATX P src/sys/arch/evbmips/conf/ZYXELKX P src/sys/arch/evbmips/conf/files.adm5120 P src/sys/arch/evbmips/conf/files.alchemy P src/sys/arch/evbmips/conf/files.gdium P src/sys/arch/evbmips/conf/files.loongson P src/sys/arch/evbmips/conf/files.malta P src/sys/arch/evbmips/conf/files.rasoc P src/sys/arch/evbmips/conf/files.rmixl P src/sys/arch/ews4800mips/conf/GENERIC P src/sys/arch/ews4800mips/conf/files.ews4800mips P src/sys/arch/hpcmips/conf/GENERIC P src/sys/arch/hpcmips/conf/LCARD P src/sys/arch/hpcmips/conf/LROUTER P src/sys/arch/hpcmips/conf/MPC303 P src/sys/arch/hpcmips/conf/TX3912 P src/sys/arch/hpcmips/conf/TX3922 P src/sys/arch/hpcmips/conf/VR41XX P src/sys/arch/hpcmips/conf/files.hpcmips P src/sys/arch/luna68k/conf/GENERIC P src/sys/arch/luna68k/conf/files.luna68k P src/sys/arch/luna68k/dev/lunaws.c U src/sys/arch/luna68k/dev/omkbdmap.c U src/sys/arch/luna68k/dev/omkbdmap.h P src/sys/arch/newsmips/conf/DEJIKO P src/sys/arch/newsmips/conf/GENERIC P src/sys/arch/newsmips/conf/WAPIKO P src/sys/arch/newsmips/conf/files.newsmips P src/sys/arch/pmax/conf/GENERIC P src/sys/arch/pmax/conf/GENERIC64 P src/sys/arch/pmax/conf/INSTALL P src/sys/arch/pmax/conf/INSTALL64 P src/sys/arch/pmax/conf/files.pmax P src/sys/arch/sbmips/conf/GENERIC P src/sys/arch/sbmips/conf/files.sbmips P src/sys/arch/sgimips/conf/GENERIC32_IP12 P src/sys/arch/sgimips/conf/GENERIC32_IP2x P src/sys/arch/sgimips/conf/GENERIC32_IP3x P src/sys/arch/sgimips/conf/files.sgimips P src/sys/arch/x86/include/intr.h P src/sys/arch/x86/x86/ipi.c P src/sys/arch/xen/conf/Makefile.xen P src/sys/dev/i2c/tps65217pmic.c P src/sys/dev/i2c/tps65217pmicreg.h U src/sys/dev/i2c/tps65217pmicvar.h P src/sys/dev/usb/if_urtwn.c P src/sys/dev/usb/if_urtwn_data.h P src/sys/dev/usb/if_urtwnreg.h P src/sys/dev/usb/if_urtwnvar.h P src/sys/dev/usb/usbdevs P src/sys/dev/usb/usbdevs.h P src/sys/dev/usb/usbdevs_data.h P src/sys/external/bsd/drm2/include/linux/ctype.h P src/sys/lib/libunwind/AddressSpace.hpp P src/sys/miscfs/kernfs/files.kernfs P src/sys/miscfs/kernfs/kernfs.h cvs update: `src/sys/miscfs/kernfs/kernfs_subr.c' is no longer in the repository P src/sys/miscfs/kernfs/kernfs_vfsops.c P src/sys/miscfs/kernfs/kernfs_vnops.c P src/sys/modules/kernfs/Makefile P src/sys/net/if_bridge.c P src/sys/net/npf/npf_conn.c P src/sys/rump/fs/lib/libkernfs/Makefile P src/sys/sys/syslog.h P src/tests/lib/libc/stdlib/t_hsearch.c P src/usr.bin/tic/tic.c P src/usr.bin/xlint/lint1/lint1.h Updating xsrc tree: P xsrc/external/mit/xf86-video-wsfb/dist/src/wsfb_driver.c Killing core files: Running the SUP scanner: SUP Scan for current starting at Mon Jul 21 03:05:07 2014 SUP Scan for current completed at Mon Jul 21 03:05:27 2014 SUP Scan for mirror starting at Mon Jul 21 03:05:27 2014 SUP Scan for mirror completed at Mon Jul 21 03:07:34 2014 Updating release-5 src tree (netbsd-5): Updating release-5 xsrc tree (netbsd-5): Running the SUP scanner: SUP Scan for release-5 starting at Mon Jul 21 03:22:50 2014 SUP Scan for release-5 completed at Mon Jul 21 03:22:58 2014 Updating release-6 src tree (netbsd-6): Updating release-6 xsrc tree (netbsd-6): Running the SUP scanner:
Re: Preparation for creating netbsd-7 branch
matt@ wrote: For the next release, core/releng should decide per current implementation: - how the default userland MACHINE_ARCH should be deteremined What do you mean by default? What (and how) MACHINE_ARCH should releng (binary builders) specify for each arm port on NetBSD 7.0 release? - how to handle migration from old ABI to new one on sysinst In essence, this is no different from upgrading an i386 userland to an amd64 userland. So, your answer is We will never prepare such upgrade path right? - which MACHINE_ARCH binaries should be prepared for official packages etc. for the new MACHINE_ARCH strategies. I have not seen an ARMv6 or ARMv7 machine without floating point yet. It doesn't answer the question at all. The question is which MACHINE_ARCH. You are making a mountain out of a molehill. Providing a simple mechanism for an optimized userland for an embedded system (which most ARMs are) is a good thing. You never mentioned such simple mechanism goal in public, did you? The probelm is all your changes have been committed without public discussion and proper article. That's all. You never answered any questions either, and you never wrote proper commit logs. (PR numbers, reports on public mailing lists etc.) You have never answered other core member's question about mips64 breakage either, put no comments to recent fixes. It looks far from proper behavior as a core member.. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
christos@ wrote: Please correct me if I am wrong: - The default userland is selected by installing the toolchain that produces that kind of userland. The binaries are branded via an Elf note that are of this kind of machine arch. - I am not sure if migration works, but presumably a hardfloat kernel should be able to handle softfloat binaries. I.e. recompilation is advised, but nothing more. - Each MACHINE should have its default MACHINE_ARCH. This could change over time. There are multiple evbarm flavors built for different hardware with different capabilities. No idea about correctness, but for NetBSD 7.0 we needs some choice. --- Izumi Tsutsui
