Re: CVS commit: src/sys
On Fri, Apr 17, 2020 at 9:02 AM Manuel Bouyer wrote: > On Fri, Apr 17, 2020 at 07:52:53AM -0700, Jason Thorpe wrote: > > > > > On Apr 17, 2020, at 7:46 AM, Robert Elz wrote: > > > > > >Date:Fri, 17 Apr 2020 15:37:33 +0200 > > >From:Manuel Bouyer > > >Message-ID: <20200417133733.ga5...@antioche.eu.org> > > > > > > | And that would be a problem for me. I regulary update a single file > to a > > > | specific revision in a source tree. > > > > > > Me too - I pull the current sh into NetBSD 8 (and I guess 9 now too, > > > though I haven't done that yet) and build it there for some people who > > > like to test and report bugs. > > > > The New Hotness (which isn't particularly new, at this point) is to > create branches and merge what you want into that branch. > > Yes, but it's much more work than 'cvs up' in a single directory or against > a few files. > The real new hotness is to use a git mirror to create a branch and then rebase it. It's no more steps to rebase a branch forward than it is to update twice... OK, don't know if it's really the right new hotness, or coldness, or lukewarm seething, but it's a strategy I've started to use to keep FreeBSD-specific changes for software that doesn't support it (yet) before I upstream (or if I upstream, sometimes the upstreams don't want to know). With NetBSD and updating /bin/sh to the latest on an old branch, I'd think that would just be creating a branch from netbsd-8, cherry picking the /bin/sh changes to that branch and then rebasing it forward as the netbsd-8 branch evolves, possibly with cherry-picking new changes as /bin/sh does in -current. It's more controlled that way, and also allows tweaks to /bin/sh if it were to become uncompilable as-is for some reason (more likely with other programs than /bin/sh). It's a little more work, but it's a lot more flexible. Warner
Re: CVS commit: src/sys/modules/compat_netbsd32
Good news everyone. Does not affect any release at all. Also might not have been a security issue, because christos did a weird thing where it is compiled but somehow still disabled. On Sun, Apr 19, 2020 at 05:40:50PM +, Maya Rashish wrote: > Module Name: src > Committed By: maya > Date: Sun Apr 19 17:40:50 UTC 2020 > > Modified Files: > src/sys/modules/compat_netbsd32: Makefile > > Log Message: > Turn off compat drm. > XXX issue security advisory > > > To generate a diff of this commit: > cvs rdiff -u -r1.32 -r1.33 src/sys/modules/compat_netbsd32/Makefile > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > Modified files: > > Index: src/sys/modules/compat_netbsd32/Makefile > diff -u src/sys/modules/compat_netbsd32/Makefile:1.32 > src/sys/modules/compat_netbsd32/Makefile:1.33 > --- src/sys/modules/compat_netbsd32/Makefile:1.32 Thu Mar 12 15:02:29 2020 > +++ src/sys/modules/compat_netbsd32/Makefile Sun Apr 19 17:40:49 2020 > @@ -1,13 +1,13 @@ > -#$NetBSD: Makefile,v 1.32 2020/03/12 15:02:29 pgoyette Exp $ > +#$NetBSD: Makefile,v 1.33 2020/04/19 17:40:49 maya Exp $ > > .include "../Makefile.inc" > .include "../Makefile.assym" > > KMOD=compat_netbsd32 > > -.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "x86_64" > -NETBSD32_DRMKMS?=yes > -.endif > +#.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "x86_64" > +#NETBSD32_DRMKMS?=yes > +#.endif > > CPPFLAGS+= -DCOMPAT_NETBSD32 > CPPFLAGS+= -DEXEC_ELF32 -DEXEC_ELF64 >
Re: CVS commit: src/sys/modules/compat_netbsd32
I almost got a heart attack between your first email and your second one, wondering how this code got re-enabled. Thanks for clarifying. Relevant example, by the way. Committed on August 20th 2019 at 09:32 https://mail-index.netbsd.org/source-changes/2019/08/20/msg108321.html Disabled by me the same day at 12:25 https://mail-index.netbsd.org/source-changes/2019/08/20/msg108332.html No rocket science here, I just saw that the code qualified as close to structurally deficient, and went ahead. In case you people are wondering, I think I did it with strictly no discussion. Unsurprisingly, it looks like it has saved us a lot of trouble here. This is what sane policy looks like. Le 19/04/2020 à 19:58, m...@netbsd.org a écrit : > Good news everyone. Does not affect any release at all. > Also might not have been a security issue, because christos did a weird > thing where it is compiled but somehow still disabled. > > On Sun, Apr 19, 2020 at 05:40:50PM +, Maya Rashish wrote: >> Module Name: src >> Committed By:maya >> Date:Sun Apr 19 17:40:50 UTC 2020 >> >> Modified Files: >> src/sys/modules/compat_netbsd32: Makefile >> >> Log Message: >> Turn off compat drm. >> XXX issue security advisory >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.32 -r1.33 src/sys/modules/compat_netbsd32/Makefile >> >> Please note that diffs are not public domain; they are subject to the >> copyright notices on the relevant files. >> > >> Modified files: >> >> Index: src/sys/modules/compat_netbsd32/Makefile >> diff -u src/sys/modules/compat_netbsd32/Makefile:1.32 >> src/sys/modules/compat_netbsd32/Makefile:1.33 >> --- src/sys/modules/compat_netbsd32/Makefile:1.32Thu Mar 12 15:02:29 2020 >> +++ src/sys/modules/compat_netbsd32/Makefile Sun Apr 19 17:40:49 2020 >> @@ -1,13 +1,13 @@ >> -# $NetBSD: Makefile,v 1.32 2020/03/12 15:02:29 pgoyette Exp $ >> +# $NetBSD: Makefile,v 1.33 2020/04/19 17:40:49 maya Exp $ >> >> .include "../Makefile.inc" >> .include "../Makefile.assym" >> >> KMOD= compat_netbsd32 >> >> -.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "x86_64" >> -NETBSD32_DRMKMS?=yes >> -.endif >> +#.if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "x86_64" >> +#NETBSD32_DRMKMS?=yes >> +#.endif >> >> CPPFLAGS+= -DCOMPAT_NETBSD32 >> CPPFLAGS+= -DEXEC_ELF32 -DEXEC_ELF64