Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Nov 2022 22:53:34 +0000
From:      bugzilla-noreply@freebsd.org
To:        ports-bugs@FreeBSD.org
Subject:   [Bug 268024] .hooks/pre-commit.d/check_portepoch broken on lines affecting PORTEPOCH comments
Message-ID:  <bug-268024-7788@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268024

            Bug ID: 268024
           Summary: .hooks/pre-commit.d/check_portepoch broken on lines
                    affecting PORTEPOCH comments
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Keywords: patch, regression
          Severity: Affects Many People
          Priority: ---
         Component: Ports Framework
          Assignee: portmgr@FreeBSD.org
          Reporter: mandree@FreeBSD.org
                CC: portmgr@FreeBSD.org, ports-bugs@FreeBSD.org
 Attachment #238381 maintainer-approval?(portmgr@FreeBSD.org)
             Flags:
                CC: portmgr@FreeBSD.org

Created attachment 238381
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D238381&action=
=3Dedit
fix proposal for check_portepoch to fix various issues with it

I was editing dns/dnsmasq-devel 2.88rc3, to upgrade to rc5, and removed a
PORTEPOCH comment. This tripped up check_portepoch, which cannot cope with a
situation that git renders PORTEPOCH diffs that do not relate to ^PORTEPOCH=
=3D23
lines, and it printed=20

[pre-commit] dropped PORTEPOCH  in dns/dnsmasq-devel/Makefile

So, because I was editing PORTEPOCH comments, git was emitting the lines, b=
ut
grep was not picking them up. Right. And then the first check for the exit 1
path was simplistic and just assumed "no new portepoch, we're broken". Untr=
ue.


To fix, only complain about an empty PORTEPOCH if we had one before. If both
old and new are empty, we may be safe, so do not complain and do not error =
out.

Also note that GNU grep complains about the regexps, because it runs withou=
t -E
option, but the basic regex has \- (you never escape -) and \+ (which has
reverse meaning, and you do not want to match multiple ^ anchors instead of
matching the literal +), so fix that, too, and be stricter to only look at
^PORTEPOCH lines that have a =3D somewhere.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-268024-7788>