I would make your fix a configure option that is off by default. It is silly that Apple makes you use sudo to tell it that a compiled code SHOULD NOT accept outside connections but they have it all bundled together without enough thought for developers.
Barry > On Aug 31, 2020, at 4:14 AM, Hapla Vaclav <vaclav.ha...@erdw.ethz.ch> wrote: > > >> On 29 Aug 2020, at 02:03, Hapla Vaclav <vaclav.ha...@erdw.ethz.ch> wrote: >> >> >> >>> On 28 Aug 2020, at 22:47, Jed Brown <j...@jedbrown.org> wrote: >>> >>> "Hapla Vaclav" <vaclav.ha...@erdw.ethz.ch> writes: >>> >>>> On MacOS, maybe you also have lots of firewall popups >>>> appearing/disappearing when running tests like >>>> Do you want the application "ex29" to accept incoming network connections? >>> >>> Is there a way to express that the application does not need (should not >>> accept) incoming connections? >> >> Oh yes, hadn't thought about before, but it's surely better to _block_ the >> incoming connections - feels safer for a user at least. >> >> But the way is the same, requiring sudo: >> >> sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add >> $PETSC_DIR/$PETSC_ARCH/tests/dm/impls/plex/tests/ex9 >> sudo /usr/libexec/ApplicationFirewall/socketfilterfw --block >> $PETSC_DIR/$PETSC_ARCH/tests/dm/impls/plex/tests/ex9 >> >> Funny enough, these commands don't fail without sudo but they have no effect. >> >>> >>> Normalizing sudo during build/testing seems really bad. >> >> I agree. It shouldn't be a normal part of the makefile. That's why I have >> been hesitant to create a MR. I think we could >> 1. just add an FAQ entry - but the patch can become out-of-date pretty >> quickly, and instructions without a patch are gonna be tedious >> 2. activate this part conditionally, requiring a user's action such as >> passing a very special variable to makefile >> 3. put it into a separate makefile and add a commented out include into >> gmakefile.test, so that the user has to explicitly uncomment the inclusion - >> or something like that >> 4. something else? > > Jed, Barry, thoughts here? > > Thanks, > Vaclav > >> >> Vaclav >