No worries. Thanks for the correction! -- Shawn Webb Cofounder / Security Engineer HardenedBSD
Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 On Sun, Apr 07, 2019 at 06:11:58PM +0200, Mariusz Zaborski wrote: > In the https://wiki.freebsd.org/AddingSyscalls we mentions that we need to > bump > __FreeBSD_version. I confirmed that with Warner. So this was my mistake. > > Thanks Shawn. > -- > Mariusz Zaborski > oshogbo//vx | http://oshogbo.vexillium.org > FreeBSD committer | https://freebsd.org > Software developer | http://wheelsystems.com > If it's not broken, let's fix it till it is!!1 > > On Sun, Apr 07, 2019 at 08:35:07AM -0700, Cy Schubert wrote: > > In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W. > > Grimes" > > writes: > > > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb > > > > <shawn.w...@hardenedbsd.org> wr > > > ote: > > > > >On Sat, Apr 06, 2019 at 09:34:26AM +0000, Mariusz Zaborski wrote: > > > > >> Author: oshogbo > > > > >> Date: Sat Apr 6 09:34:26 2019 > > > > >> New Revision: 345982 > > > > >> URL: https://svnweb.freebsd.org/changeset/base/345982 > > > > >> > > > > >> Log: > > > > >> Introduce funlinkat syscall that always us to check if we are > > > > >removing > > > > >> the file associated with the given file descriptor. > > > > >> > > > > >> Reviewed by: kib, asomers > > > > >> Reviewed by: cem, jilles, brooks (they reviewed previous > > > > >> version) > > > > >> Discussed with: pjd, and many others > > > > >> Differential Revision: https://reviews.freebsd.org/D14567 > > > > > > > > > >Hey Mariusz, > > > > > > > > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls? > > > > >I can't remember off-hand. > > > > > > > > > >Thanks, > > > > > > > > I don't think so. Why force the rebuild of all ports through poudriere > > > > over > > > something that would never affect any of them? > > > > > > So that you can if version >= foo to know it is safe to use the new > > > syscal? > > > Or if version < foo you must use the old way. > > > > Granted. However we do need something to avoid gratuitous rebuilds of > > ports. > > > > Personally, my poudriere script adjusts the pkg version > > ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with > > that of the jail version (reported by poudriere jail -i -j $JAIL), > > rebuilding all ports when I (the human) determines when the machine > > should rebuild all ports with -c. > > > > In that regard FreeBSD version bumps occasionally seem a little > > gratuitous. Using the same indicator to tell whether software should be > > able to use a new feature and when ports build infrastructure should > > summarily delete all packages forcing a rebuild of absolutely > > everything is probably not the best. > > > > Just throwing out an idea, what if poudriere considers the first N > > bytes of __FreeBSD_version significant? Having said that, looking at > > __FreeBSD_version, I don't think we have enough digits to do what I was > > planning on suggesting. But, you get the idea of what I'm driving at. > > Maybe a new macro such as __FreeBSD_ports that is incremented every > > time a change that affects ports? > > > > Anyhow, I'm not too terribly concerned as what I have (selfishly > > speaking) works. But we may as a group might want to consider this at > > some point to build some efficiency into the ports part of the equation. > > > > > > -- > > Cheers, > > Cy Schubert <cy.schub...@cschubert.com> > > FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org > > > > The need of the many outweighs the greed of the few. > > > >
signature.asc
Description: PGP signature
