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
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
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
