Re: devel/pango checksum error

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

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...

>
> Tom
>


-- 
----