Re: devel/pango checksum error

[Peter Lai <cowbert%gmail.com@localhost>]

On Wed, Jun 16, 2021 at 6:16 AM Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
>
> On Wed, 16 Jun 2021 at 10:54, Thomas Mueller <mueller6725%twc.com@localhost> wrote:
> >
> > from Patrick Welche:
> > X-CMAE-Envelope: MS4xfJHPDL9TraKhSyE9XNNKut/yh182Cz2M+wIjNmPusxe7CYaCvIq8B5O2UALALtJnPy7RscjcInOgom3d7H1wLdG3PkwP7MOSg/PCIh9nUxGA8un9GrLA
> >  171FB/MDCBQjaKkdZrMIHFTGraBYhk1iJnQPm9JQ9Q47rwtTP/CRhSTbCOorRBBwVgcFPdxPPF+big==
> >
> > > On Wed, Jun 16, 2021 at 08:23:30AM +0000, Thomas Mueller wrote:
> > > > Also, I retried devel/libuv after make clean, but got the same SHA1 mismatch.
> >
> > > Given your pango note, I would start by checking the tarball so we can
> > > agree that we are all trying to compile the same code.
> >
> > > Cheers,
> >
> > > Patrick
> >
> > How would I check the tarball?  I tried tar xvf and got an error.
> >
> > So I went to the websites (pango and libuv) with elinks and downloaded the distfiles, same version number.
> >
> > There was a difference (both cases).
> >
> > Is "cvs update" unreliable?
>
> You don't download the distfiles using cvs; you use one of the methods
> available in pkgsrc itself.
>
> There have been occasions when cvs updates have finished halfway with
> an obscure (for me) error message, but - usually after waiting a bit -
> it succeeds. I do all my updates by cvs (for src, xsrc and pkgsrc; wip
> is of course git).
>
> You may get a checksum error on a distfile from time to time when it
> has been downloaded directly from the upstream distribution, the
> upstream packages sometimes get replaced with files with identical
> names when the developers have discovered minor problems with them
> (this is of course bad, but happens - if you hit such an occasion, you
> should test locally with NOCHECKSUM=yes, if it works, then do 'make
> clean && make distinfo && cvs diff -u' and perhaps post the output of
> the last command here or even file a pr to point out to the package
> developer the source change).
>
> Here is what happens when downloading:
>
> # pwd
> /usr/pkgsrc/devel/pango
> # cvs up -dPA
> cvs update: Updating .
> cvs update: Updating files
> cvs update: Updating patches
> # make fetch
> => Bootstrap dependency digest>=20010302: found digest-20190127
> => Fetching pango-1.48.4.tar.xz
> => Total size: 1791332 bytes
> Trying [2620:52:3:1:5054:ff:fede:8714]:443 ...
> ftp: Can't connect to `2620:52:3:1:5054:ff:fede:8714:443': No route to host
> Trying [2620:52:3:1:5054:ff:fedd:5ad0]:443 ...
> ftp: Can't connect to `2620:52:3:1:5054:ff:fedd:5ad0:443': No route to host
> Trying [2620:52:3:1:5054:ff:fe0d:ee0f]:443 ...
> ftp: Can't connect to `2620:52:3:1:5054:ff:fe0d:ee0f:443': No route to host
> Trying 8.43.85.29:443 ...
> Requesting https://download.gnome.org/sources/pango/1.48/pango-1.48.4.tar.xz
> Redirected to https://fr.rpmfind.net/linux/gnome.org/sources/pango/1.48/pango-1.48.4.tar.xz
> Requesting https://fr.rpmfind.net/linux/gnome.org/sources/pango/1.48/pango-1.48.4.tar.xz
> 100% |******************************************************************************************************************************|
>  1749 KiB    2.13 MiB/s    00:00 ETA
> 1791332 bytes retrieved in 00:00 (2.13 MiB/s)
> # make extract
> => Bootstrap dependency digest>=20010302: found digest-20190127
> => Checksum SHA1 OK for pango-1.48.4.tar.xz
> => Checksum RMD160 OK for pango-1.48.4.tar.xz
> => Checksum SHA512 OK for pango-1.48.4.tar.xz
> ......
>
>
> > Should I switch to hg?  Building mercurial took only a couple minutes.  Is mercurial more reliable?
> >
> > Or should I switch to the other hard drive, now in an external SATA hard drive dock which is part of the computer case (current NetBSD amd64 and i386 already installed)?
>
> That's beside the point. One should be reasonably confident in one's
> hardware...

Seeing as how Tom appears to be having isolated build problems
associated with intermittent segfault/kernel panic during
memory-utilizing compiles and checksum failing downloads; are all
symptoms of RAM failure..