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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060123095213.GV1020>