Re: CVS commit: src/share/mk
On Mon, Jan 21, 2019 at 04:11:55PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Mon Jan 21 21:11:55 UTC 2019 > > Modified Files: > src/share/mk: bsd.dep.mk bsd.hostprog.mk bsd.info.mk bsd.kmodule.mk > bsd.lib.mk bsd.man.mk bsd.prog.mk bsd.sys.mk bsd.test.mk bsd.x11.mk > sys.mk > > Log Message: > Most of the mv operations are to move temporary files to their final place. > Some use -f, others don't. This can lead to spurious build failures when > the user performing the build changes. Centralize, and always use -f. At least the sys.mk part of this breaks standalone Makefiles, because MV is not defined. Joerg
Re: CVS commit: src/usr.bin/crunch/crunchgen
On Thu, Dec 19, 2019 at 12:27:23PM -0500, Christos Zoulas wrote: > On Dec 19, 4:19pm, jo...@bec.de (Joerg Sonnenberger) wrote: > -- Subject: Re: CVS commit: src/usr.bin/crunch/crunchgen > > | > I think that there are two uses: install media and rescue. I can reinstate > | > it for rescue. Is that ok? Note that by default both ssp and fortify are > | > off for most things, so my change was mostly a no-op for the default > settings. > | > | We seem to default to off for more things, PIE too for example. > > Indeed, I also dislike the alphabet soup of flags for disabling > things. I propose that instead we provide a way to add a preamble > to the generated Makefile via -f file, default to a > either a built-in configuration file, or one installed in the tree. > It is inappropriate for crunchgen to have knowledge of variables > specific to our build system that change over time. > > So I propose: > > 1. to make that change [configuration file] > 2. leave the defaults as they are for the installation binaries > 3. change the defaults to turn nothing off for the rescue binaries With the exception of the default, I agree. IMO crunchgen is a general purpose tool. It is used in different circumstances and shouldn't dictate whether "normal" use is space constrained or not. Joerg
Re: CVS commit: src/usr.bin/crunch/crunchgen
On Dec 19, 4:19pm, jo...@bec.de (Joerg Sonnenberger) wrote: -- Subject: Re: CVS commit: src/usr.bin/crunch/crunchgen | > I think that there are two uses: install media and rescue. I can reinstate | > it for rescue. Is that ok? Note that by default both ssp and fortify are | > off for most things, so my change was mostly a no-op for the default settings. | | We seem to default to off for more things, PIE too for example. Indeed, I also dislike the alphabet soup of flags for disabling things. I propose that instead we provide a way to add a preamble to the generated Makefile via -f file, default to a either a built-in configuration file, or one installed in the tree. It is inappropriate for crunchgen to have knowledge of variables specific to our build system that change over time. So I propose: 1. to make that change [configuration file] 2. leave the defaults as they are for the installation binaries 3. change the defaults to turn nothing off for the rescue binaries christos
Re: CVS commit: src
> Date: Thu, 19 Dec 2019 08:19:07 +0100 > From: Maxime Villard > > I think you meant to say "REMOVING things you don't like". Correct, I made an editing error. Sorry for the confusion. > In the meantime, I have absolutely no intent to reinstate filemon. You can > reinstate it if you want, but it should come as no surprise to you in the > near future that filemon, after whatever "necessary" discussion or different > forms of bureaucratic idiocy you want to throw at it, will be deleted almost > as fast as it came back from the attic. Especially considering the emails > sent from the other people since I proceeded. This is not negotiable. It is core's position that the filemon removal should be undone for the time being, so please go ahead and undo it. Thanks, -Riastradh, on behalf of core
Re: CVS commit: src/usr.bin/crunch/crunchgen
On Thu, Dec 19, 2019 at 01:46:43PM -, Christos Zoulas wrote: > In article <20191218222723.ga17...@bec.de>, > Joerg Sonnenberger wrote: > >On Wed, Dec 18, 2019 at 03:51:21PM -, Christos Zoulas wrote: > >> In article <20191218152113.ga7...@bec.de>, > >> Joerg Sonnenberger wrote: > >> >On Tue, Dec 17, 2019 at 09:16:04PM -0500, Christos Zoulas wrote: > >> >> Module Name:src > >> >> Committed By: christos > >> >> Date: Wed Dec 18 02:16:04 UTC 2019 > >> >> > >> >> Modified Files: > >> >> src/usr.bin/crunch/crunchgen: crunchgen.1 crunchgen.c > >> >> > >> >> Log Message: > >> >> Also disable ssp and fortify by default. > >> > > >> >Why? > >> > >> Size reduction on install media. There are flags to turn it on. > > > >Not all users of crunchgen are space constrained, so this seems like a > >bad default to me. > > I think that there are two uses: install media and rescue. I can reinstate > it for rescue. Is that ok? Note that by default both ssp and fortify are > off for most things, so my change was mostly a no-op for the default settings. We seem to default to off for more things, PIE too for example. Joerg
Re: CVS commit: src/usr.bin/crunch/crunchgen
In article <20191218222723.ga17...@bec.de>, Joerg Sonnenberger wrote: >On Wed, Dec 18, 2019 at 03:51:21PM -, Christos Zoulas wrote: >> In article <20191218152113.ga7...@bec.de>, >> Joerg Sonnenberger wrote: >> >On Tue, Dec 17, 2019 at 09:16:04PM -0500, Christos Zoulas wrote: >> >> Module Name: src >> >> Committed By: christos >> >> Date: Wed Dec 18 02:16:04 UTC 2019 >> >> >> >> Modified Files: >> >> src/usr.bin/crunch/crunchgen: crunchgen.1 crunchgen.c >> >> >> >> Log Message: >> >> Also disable ssp and fortify by default. >> > >> >Why? >> >> Size reduction on install media. There are flags to turn it on. > >Not all users of crunchgen are space constrained, so this seems like a >bad default to me. I think that there are two uses: install media and rescue. I can reinstate it for rescue. Is that ok? Note that by default both ssp and fortify are off for most things, so my change was mostly a no-op for the default settings. christos
Re: CVS commit: src
On Wed, Dec 18, 2019, 10:45 AM wrote: > On Wed, Dec 18, 2019 at 06:47:44AM -0500, Christos Zoulas wrote: > > While there was no discussion, it is more efficient to have the > discussion > > whether we should put it back or not (instead of putting it back first > and > > having the discussion). Of course we should fix the build first since it > seems > > to be broken. > > > > The reality of the situation is that the syscall race has been there for > months > > and nobody has taken responsibility to fix it. The code is in version > control, > > so someone should fix it first and then we can discuss if we should > bring it > > back. > > > I'd like to also publicly object to the removal of the code from bmake > (I responded privately at first). > FreeBSD has filemon, and I suspect it has more acceptance there, but > maxv stated he will propose it. > Sharing the code with FreeBSD is more than worth the 200 unused-by-us > lines of code, and it's already optional. > No rush though. Let's wait to see what they say. > FreeBSD definitely uses filemon in our build system... I've not looked at the details of this removal to know if that messes things up for us or not. Warner I have no objections to removing the kernel module. >
