Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Jan 2006 20:52:13 +1100
From:      Edwin Groothuis <edwin@mavetju.org>
To:        Darren Pilgrim <darren.pilgrim@bitfreak.org>
Cc:        cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org
Subject:   Re: "SHA256ify" commits
Message-ID:  <20060123095213.GV1020@k7.mavetju>
In-Reply-To: <000001c61faf$30bcdf60$672a15ac@smiley>
References:  <200601222124.k0MLO5A9083860@repoman.freebsd.org> <000001c61faf$30bcdf60$672a15ac@smiley>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sun, Jan 22, 2006 at 03:54:30PM -0800, Darren Pilgrim wrote:
> There's no criticism here, just one geek's interested query.  I'm already
> familiar with the reasons for moving to SHA256, but how is this process
> being accomplished?  What are you using to calculate and insert the new
> hashes?  What conditions result in the "manually checked and updated"
> commit?  If there's previous list traffic answering these questions, by all
> means, point me in a direction.

The way it's done right now is best described as "blunt axe":

- Run "make checksun", which downloads the files and checks them
  for validity.

- Run "make makesum", which adds the SHA256 lines

- Diff the old distinfo and new distinfo for lost lines.

- If no lost lines, commit. The commit info only shows +n and -0.


The "manually checked and updated" ones are ones on which the diff
showed -n (where n!=0) and checked for validity, for example the
relocation of SIZE or extra files which the normal "mkae checksum"
didn't fetch.

Of course I'm going to miss one or two lines, but a distinfo parser
will later on tell me what I'm still missing.

Edwin

-- 
Edwin Groothuis      |            Personal website: http://www.mavetju.org
edwin@mavetju.org    |          Weblog: http://weblog.barnet.com.au/edwin/



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20060123095213.GV1020>