Re: weekly locate error Was: September 2024 stabilization week

On 9/30/24 16:28, void wrote:
> On Mon, Sep 30, 2024 at 02:08:18PM -0700, Gleb Smirnoff wrote:
> 
>> M> > Manual run of the periodic job doesn't reproduce the problem :(
>> M>
>> M> Backing out commit f62c1f3f8e91c78d402e1db4e518e4899a4ba2b9 
>> resolves it for
>> M> me,
> 
> Sorry but I'm quite dense regarding git. Can you describe how exactly
> what steps you took to 'back out of 
> f62c1f3f8e91c78d402e1db4e518e4899a4ba2b9'
> 
> I know about git pull and clone and reset --hard and git rm and that's 
> about it ;)

You could just apply this manually for now:

diff --git a/usr.bin/locate/locate/updatedb.sh 
b/usr.bin/locate/locate/updatedb.sh
index ca1a79116a91..2c06e06fae4d 100644
--- a/usr.bin/locate/locate/updatedb.sh
+++ b/usr.bin/locate/locate/updatedb.sh
@@ -96,5 +96,5 @@ then
                 echo "updatedb: locate database $tmp is empty" >&2
                 exit 1
         fi
-       install $tmp $FCODES
+       cat $tmp > $FCODES
  fi

It might be that the better long-term approach is to teach updatedb.sh 
how to drop privileges and push that out of the periodic script to avoid 
surprises like this from the different execution environments.  This 
/feels/ like the kind of thing we could take an opinionated stance on, 
maybe providing an escape hatch of some sort if someone really wants to 
complain that they can't document all filenames on the system.

Thanks,

Kyle Evans