Re: cvs init
On Fri, 2019-02-08 at 01:15 -0500, David H. Gutteridge wrote: > On Thu, 07 Feb 2019, at 13:46:00 -0500, Greg Troxel wrote: > > > $ cd /tmp > > > $ mkdir foo > > > $ cvs -d /tmp/foo init > > > cvs [init aborted]: init to an existing repository is restricted > > > to > > members of the group cvsadmin > > > $ grep cvsadmin /etc/group > > > $ > > > > > > I thought that if the cvsadmin group didn't exist on the system, > > this > > > restriction would be completely ignored? (according to "cvs admin" > > command - > > > no mention of it being applicable at all to "cvs init") > > > > I just did "cvs -d /tmp/foo init" without creating foo first, and it > > worked fine (netbsd-8). > > > > The error is about running init on an *existing* repository. > > > > I don't see that rerunning init on a repo that exists is something > > anybody really wants to do, and if they do why using rm first is a > > real problem. > > The CVS documentation for version 1.12.13 states: > > "cvs init is careful to never overwrite any existing files in the > repository, so no harm is done if you run cvs init on an already set- > up repository." > https://web.archive.org/web/20111020045251/http://ximbiot.com/cvs/manual/cvs-1.12.13/cvs_2.html#SEC2 I realized I may have been unclear: I wasn't advocating for that as a normal practice, or denying the code treats this as an error. I meant that it's kind of counterintuitive to put a statement like that in documentation without a caveat. (Basically what everyone else is saying too.) > > As for the man page omission, maybe see if the bug is in upstream > > and > > file a bug with them ;-) ? > > > > We could change the code to just not allow init of an existing dir > > at > > all. > > There is also a related NetBSD PR filed back in 2011: > http://gnats.netbsd.org/45182 That PR is no longer relevant, it was addressed by christos@ in 2011. Dave
Re: Automated report: NetBSD-current/i386 test failure
The NetBSD Test Fixture wrote: > The newly failing test cases are: > > dev/raidframe/t_raid:raid1_comp0fail > dev/raidframe/t_raid:raid1_compfail > dev/raidframe/t_raid:raid1_normal > dev/raidframe/t_raid:raid5_compfail > dev/raidframe/t_raid:raid5_normal This was a duplicate report, sorry about that. These test failures have alrady been fixed. -- Andreas Gustafsson, g...@gson.org
Re: cvs init
On Thu, 07 Feb 2019, at 13:46:00 -0500, Greg Troxel wrote: > > $ cd /tmp > > $ mkdir foo > > $ cvs -d /tmp/foo init > > cvs [init aborted]: init to an existing repository is restricted to > members of the group cvsadmin > > $ grep cvsadmin /etc/group > > $ > > > > I thought that if the cvsadmin group didn't exist on the system, > this > > restriction would be completely ignored? (according to "cvs admin" > command - > > no mention of it being applicable at all to "cvs init") > > I just did "cvs -d /tmp/foo init" without creating foo first, and it > worked fine (netbsd-8). > > The error is about running init on an *existing* repository. > > I don't see that rerunning init on a repo that exists is something > anybody really wants to do, and if they do why using rm first is a > real problem. The CVS documentation for version 1.12.13 states: "cvs init is careful to never overwrite any existing files in the repository, so no harm is done if you run cvs init on an already set-up repository." https://web.archive.org/web/20111020045251/http://ximbiot.com/cvs/manual/cvs-1.12.13/cvs_2.html#SEC2 > As for the man page omission, maybe see if the bug is in upstream and > file a bug with them ;-) ? > > We could change the code to just not allow init of an existing dir at > all. There is also a related NetBSD PR filed back in 2011: http://gnats.netbsd.org/45182 Regards, Dave
daily CVS update output
Updating src tree: P src/build.sh P src/distrib/acorn32/ramdisk/Makefile P src/distrib/cats/ramdisk/Makefile P src/distrib/newsmips/floppies/ramdisk/Makefile P src/distrib/sets/lists/comp/ad.arm P src/distrib/sgimips/ramdisk/Makefile P src/distrib/sun3/ramdisk/Makefile P src/doc/3RDPARTY P src/doc/CHANGES P src/external/bsd/dhcpcd/dist/hooks/dhcpcd-run-hooks.in P src/external/bsd/dhcpcd/dist/src/arp.c P src/external/bsd/dhcpcd/dist/src/arp.h P src/external/bsd/dhcpcd/dist/src/common.h P src/external/bsd/dhcpcd/dist/src/defs.h P src/external/bsd/dhcpcd/dist/src/dhcp.c P src/external/bsd/dhcpcd/dist/src/dhcp.h P src/external/bsd/dhcpcd/dist/src/dhcp6.c P src/external/bsd/dhcpcd/dist/src/dhcp6.h P src/external/bsd/dhcpcd/dist/src/dhcpcd.c P src/external/bsd/dhcpcd/dist/src/dhcpcd.h P src/external/bsd/dhcpcd/dist/src/if-bsd.c P src/external/bsd/dhcpcd/dist/src/if-options.c P src/external/bsd/dhcpcd/dist/src/if.c P src/external/bsd/dhcpcd/dist/src/ipv4.c P src/external/bsd/dhcpcd/dist/src/ipv4.h P src/external/bsd/dhcpcd/dist/src/ipv4ll.h P src/external/bsd/dhcpcd/dist/src/ipv6.c P src/external/bsd/dhcpcd/dist/src/ipv6.h P src/external/bsd/dhcpcd/dist/src/ipv6nd.c P src/external/bsd/dhcpcd/dist/src/ipv6nd.h P src/external/bsd/dhcpcd/dist/src/script.c P src/external/bsd/dhcpcd/sbin/dhcpcd/Makefile P src/external/bsd/pkg_install/Makefile.inc P src/external/gpl3/binutils/dist/bfd/config.bfd P src/external/gpl3/binutils.old/dist/bfd/config.bfd P src/external/gpl3/gcc/README.gcc7 P src/external/gpl3/gcc/dist/gcc/config.gcc P src/external/gpl3/gcc/dist/gcc/config/arm/bpabi.h P src/external/gpl3/gcc/dist/libgcc/config.host P src/external/gpl3/gcc/dist/libgcc/config/arm/t-netbsd-eabi P src/external/gpl3/gcc/lib/libbacktrace/arch/m68000/backtrace-supported.h P src/external/gpl3/gcc/lib/libgcc/arch/earm/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earm/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmeb/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmeb/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmhf/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmhf/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmhfeb/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmhfeb/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv4/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv4/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv4eb/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv4eb/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv6/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv6/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv6eb/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv6eb/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv6hf/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv6hf/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv6hfeb/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv6hfeb/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv7/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv7/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv7eb/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv7eb/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv7hf/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv7hf/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv7hfeb/defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/earmv7hfeb/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/arch/m68000/auto-target.h P src/external/gpl3/gcc/lib/libgcc/arch/m68000/defs.mk U src/external/gpl3/gcc/lib/libgcc/arch/m68000/gthr-defs.mk P src/external/gpl3/gcc/lib/libgcc/libgcov/arch/m68000/defs.mk P src/external/gpl3/gcc/lib/libgcc/libgcov/arch/m68000/gcov-iov.h P src/external/gpl3/gcc/lib/libgomp/arch/m68000/config.h P src/external/gpl3/gcc/lib/libgomp/arch/m68000/libgomp_f.h P src/external/gpl3/gcc/lib/libgomp/arch/m68000/omp.h P src/external/gpl3/gcc/lib/libobjc/arch/m68000/defs.mk P src/external/gpl3/gcc/lib/libstdc++-v3/arch/m68000/c++config.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/m68000/cxxabi_tweaks.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/m68000/defs.mk P src/external/gpl3/gcc/lib/libstdc++-v3/arch/m68000/gstdint.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/m68000/gthr-posix.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/m68000/gthr-single.h P src/external/gpl3/gcc/lib/libstdc++-v3/arch/m68000/gthr.h P src/external/gpl3/gcc/usr.bin/backend/Makefile U src/external/gpl3/gcc/usr.bin/common-target/arch/m68000.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earm/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earm/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earm/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmeb/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmeb/defs.mk P src/external/gpl3/gcc/usr.bin/gcc/arch/earmeb/tm.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhf/configargs.h P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhf/defs.mk P
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: dev/raidframe/t_raid:raid1_comp0fail dev/raidframe/t_raid:raid1_compfail dev/raidframe/t_raid:raid1_normal dev/raidframe/t_raid:raid5_compfail dev/raidframe/t_raid:raid5_normal The above tests failed in each of the last 4 test runs, and passed in at least 26 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2019.02.05.17.13.37 christos src/sys/dev/raidframe/rf_compat80.c,v 1.9 2019.02.05.17.13.37 christos src/sys/dev/raidframe/rf_netbsd.h,v 1.31 2019.02.05.17.13.37 christos src/sys/dev/raidframe/rf_netbsdkintf.c,v 1.366 2019.02.05.17.30.19 kamil src/tests/lib/libc/stdio/t_fopen.c,v 1.6 2019.02.05.19.42.31 christos src/sys/dev/raidframe/rf_compat80.c,v 1.10 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.02.html#2019.02.05.19.42.31
re: README: gcc 7 switch coming to a port near you!
the build problem for pkg_install should be fixed now. .mrg.
Re: README: gcc 7 switch coming to a port near you!
On Thu, Feb 07, 2019 at 11:10:30AM -0600, John D. Baker wrote:
> [...]
> --- cleandir-external ---
> --- cleandir-lib ---
> cleandir ===> external/bsd/pkg_install/lib
> [...]
> --- cleandir-external ---
> nbmake[7]: "/x/current/src/external/bsd/pkg_install/lib/../Makefile.inc" line
> 16: Malformed conditional (defined(HAVE_GCC) && ${HAVE_GCC} == 7 &&
> ${ACTIVE_CC} == "gcc")
> [...]
Try the attached version.
Joerg
Index: Makefile.inc
===
RCS file: /cvsroot/src/external/bsd/pkg_install/Makefile.inc,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile.inc
--- Makefile.inc5 Feb 2019 11:37:18 - 1.5
+++ Makefile.inc7 Feb 2019 22:15:06 -
@@ -13,7 +13,7 @@ WARNS=4
CWARNFLAGS+= -Wno-missing-noreturn
# show_version() does not return
-.if defined(HAVE_GCC) && ${HAVE_GCC} == 7 && ${ACTIVE_CC} == "gcc"
-COPTS.main.c+= -Wno-error=implicit-fallthrough
-COPTS.pkg_delete.c+= -Wno-error=implicit-fallthrough
+.if ${HAVE_GCC:U0} == 7
+COPTS.main.c+= ${${ACTIVE_CC} == "gcc" :?
-Wno-error=implicit-fallthrough :}
+COPTS.pkg_delete.c+= ${${ACTIVE_CC} == "gcc" :?
-Wno-error=implicit-fallthrough :}
.endif
Re: README: gcc 7 switch coming to a port near you!
On Thu, 7 Feb 2019, Anders Lindgren wrote:
> A quick test suggest this will happen if ${ACTIVE_CC} simply isn't defined
> when the expression is evaluated, effectively yielding:
>
> defined(7) && 7 == 7 && == "gcc"
That makes sense. Since this is a "cleandir" operation, there is no
ACTIVE_CC (I should think), so the variable is undefined or empty.
Perhaps ACTIVE_CC needs a 'defined()' test as well, or at least wrap in
double-quotes for a valid string comparison.
Just did this now (wrap ${ACTIVE_CC} in double-quotes: "${ACTIVE_CC}")
in the reported failing Makefile.inc and started the build over. The
clean-dir for "...pkg_install/lib" appears to have succeeded. The build
(target=sparc) is proceeding.
Although I see numerous Makefile* files with this same idiom, perhaps
it was just this one "Makefile.inc" that was affected due to the
conditional being evaluated outside of a target where ACTIVE_CC would
otherwise be guaranteed to be defined?
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: README: gcc 7 switch coming to a port near you!
On Thu, 7 Feb 2019, John D. Baker wrote:
On Thu, 07 Feb 2019 22:27:58 +1100, matthew green
wrote:
if you'd like to test now from -current, build a clean tree
with build.sh -V HAVE_GCC=7. it should just work..
How clean is "clean tree"? I'm simply performing a non-update build
into objdir last populated by a previous update build (w/o HAVE_GCC=7).
I'm getting the following failure (amd64-8.0_STABLE host):
[...]
--- cleandir-external ---
--- cleandir-lib ---
cleandir ===> external/bsd/pkg_install/lib
[...]
--- cleandir-external ---
nbmake[7]: "/x/current/src/external/bsd/pkg_install/lib/../Makefile.inc" line 16: Malformed conditional
(defined(HAVE_GCC) && ${HAVE_GCC} == 7 && ${ACTIVE_CC} == "gcc")
[...]
FWIW, I hade the same problem (amd64 host, amiga target) with a completely
new and empty objdir and sources as of this morning, CET.
A quick test suggest this will happen if ${ACTIVE_CC} simply isn't defined
when the expression is evaluated, effectively yielding:
defined(7) && 7 == 7 && == "gcc"
/ali
Re: cvs init
Patrick Welche writes: > $ cd /tmp > $ mkdir foo > $ cvs -d /tmp/foo init > cvs [init aborted]: init to an existing repository is restricted to members > of the group cvsadmin > $ grep cvsadmin /etc/group > $ > > I thought that if the cvsadmin group didn't exist on the system, this > restriction would be completely ignored? (according to "cvs admin" command - > no mention of it being applicable at all to "cvs init") I just did "cvs -d /tmp/foo init" without creating foo first, and it worked fine (netbsd-8). The error is about running init on an *existing* repository. I don't see that rerunning init on a repo that exists is something anybody really wants to do, and if they do why using rm first is a real problem. As for the man page omission, maybe see if the bug is in upstream and file a bug with them ;-) ? We could change the code to just not allow init of an existing dir at all.
Re: README: gcc 7 switch coming to a port near you!
On Thu, 07 Feb 2019 22:27:58 +1100, matthew green
wrote:
> if you'd like to test now from -current, build a clean tree
> with build.sh -V HAVE_GCC=7. it should just work..
How clean is "clean tree"? I'm simply performing a non-update build
into objdir last populated by a previous update build (w/o HAVE_GCC=7).
I'm getting the following failure (amd64-8.0_STABLE host):
[...]
--- cleandir-external ---
--- cleandir-lib ---
cleandir ===> external/bsd/pkg_install/lib
[...]
--- cleandir-external ---
nbmake[7]: "/x/current/src/external/bsd/pkg_install/lib/../Makefile.inc" line
16: Malformed conditional (defined(HAVE_GCC) && ${HAVE_GCC} == 7 &&
${ACTIVE_CC} == "gcc")
[...]
I see a number of Makefile* files with this idiom, but this is the only
one it's tripping on (so far). I don't see what it thinks is malformed
about it. Manually nuking the affected objdir sub-tree doesn't affect
the result.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
cvs init
$ cd /tmp $ mkdir foo $ cvs -d /tmp/foo init cvs [init aborted]: init to an existing repository is restricted to members of the group cvsadmin $ grep cvsadmin /etc/group $ I thought that if the cvsadmin group didn't exist on the system, this restriction would be completely ignored? (according to "cvs admin" command - no mention of it being applicable at all to "cvs init") I'm pretty sure this used to work... (today's amd64 -current) Thoughts? Cheers, Patrick
README: gcc 7 switch coming to a port near you!
hi folks. i plan to switch amd64 and arm64 to GCC 7 soon. i386, sparc*, mips, ppc, and alpha are probably ready and tested enough for anyone else to try out. 32 bit arm is only just now working so not well tested yet. hppa, m68k, vax, and sh3 all build but have not been tested yet. ia64 and ppc64 are currently not building, and i haven't looked at the hopefully revived riscv port yet, or the or1k. if you'd like to test now from -current, build a clean tree with build.sh -V HAVE_GCC=7. it should just work.. if you need to switch back to GCC 6 afterwards, you'll need to set HAVE_GCC=6 and build a clean install. .mrg.
Re: compiling if_mue.c fails
Hi, On Thu, Feb 07, 2019 at 07:56:53AM +0900, Rin Okuyama wrote: > > Should be fixed now. Sorry for breakage. compiles fine, thanks for the quick fix. Kurt
