Re: [PATCH 07/24] gnu: compression: Add snappy.

Re: [PATCH 07/24] gnu: compression: Add snappy.

[David Craven]

> Also there is a real release that shouldn't require autoreconf phase:
> <https://github.com/google/snappy/releases/download/1.1.3/snappy-1.1.3.tar.gz>
> Did you try using it?

Just did, and requires running autoreconf too...

Re: [PATCH 07/24] gnu: compression: Add snappy.

[Alex Kost]

David Craven (2016-08-17 11:30 +0300) wrote:

>> Also there is a real release that shouldn't require autoreconf phase:
>> <https://github.com/google/snappy/releases/download/1.1.3/snappy-1.1.3.tar.gz>
>> Did you try using it?
>
> Just did, and requires running autoreconf too...

I don't believe you :-)

I've just tried, and autoreconf is not needed for this tarball:

(define-public snappy
  (package
    (name "snappy")
    (version "1.1.3")
    (source (origin
              (method url-fetch)
              (uri (string-append
                    "https://github.com/google/snappy/releases/download/"
                    version "/" name "-" version ".tar.gz"))
              (sha256
               (base32
                "1wzf8yif5ym2gj52db6v5m1pxnmn258i38x7llk9x346y2nq47ig"))))
    (build-system gnu-build-system)
    (home-page "https://github.com/google/snappy")
    (synopsis "Fast compressor/decompressor")
    (description "Snappy is a compression/decompression library. It does not
aim for maximum compression, or compatibility with any other compression library;
instead, it aims for very high speeds and reasonable compression. For instance,
compared to the fastest mode of zlib, Snappy is an order of magnitude faster
for most inputs, but the resulting compressed files are anywhere from 20% to
100% bigger.")
    (license license:asl2.0)))

-- 
Alex

Re: [PATCH 07/24] gnu: compression: Add snappy.

[David Craven]

> I don't believe you :-)

Oh, that's embarrassing. I must have forgotten to change the hash and
guix cached the tarball. Is that possible?

Re: [PATCH 07/24] gnu: compression: Add snappy.

[David Craven]

>> I don't believe you :-)
>
> Oh, that's embarrassing. I must have forgotten to change the hash and
> guix cached the tarball. Is that possible?

Sorry about that. I make many stupid mistakes, but I'm not a liar... ;-)

Re: [PATCH 07/24] gnu: compression: Add snappy.

[Leo Famulari]

On Wed, Aug 17, 2016 at 09:20:42PM +0200, David Craven wrote:
> Oh, that's embarrassing. I must have forgotten to change the hash and
> guix cached the tarball. Is that possible?

If the hash is matched in the store, the URL is not used, so you won't
see an incorrect URL fail to match the hash.

This is a common cause of buggy patches.

I wonder, are there any drawbacks of making the linter check that the
URL provides the data named by the hash?

Re: [PATCH 07/24] gnu: compression: Add snappy.

[Alex Kost]

David Craven (2016-08-17 22:27 +0300) wrote:

>>> I don't believe you :-)
>>
>> Oh, that's embarrassing. I must have forgotten to change the hash and
>> guix cached the tarball. Is that possible?
>
> Sorry about that. I make many stupid mistakes, but I'm not a liar... ;-)

Oh, I didn't mean that!  I just wanted to say that it works as expected,
so you probably made some mistake.  As for the hash, yes it's possible
as Leo explained.

-- 
Alex

Re: [PATCH 07/24] gnu: compression: Add snappy.

[David Craven]

> I wonder, are there any drawbacks of making the linter check that the
> URL provides the data named by the hash?

That may be useful. I think if guix refresh would accept a version
flag, and possibly a force flag, that would also be useful.

The version flag would be used as follows:

guix refresh qtbase -u --version=5.7.0

If the version is already set to 5.7.0 a -f flag would download and
update the hash anyway. This is useful when the download url has
changed, but the version hasn't as in the snappy example. I think
these two features could make guix refresh more generally applicable,
to packages that don't have an automatic updater.

‘guix lint’ URL checks

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Aug 17, 2016 at 09:20:42PM +0200, David Craven wrote:
>> Oh, that's embarrassing. I must have forgotten to change the hash and
>> guix cached the tarball. Is that possible?
>
> If the hash is matched in the store, the URL is not used, so you won't
> see an incorrect URL fail to match the hash.
>
> This is a common cause of buggy patches.
>
> I wonder, are there any drawbacks of making the linter check that the
> URL provides the data named by the hash?

The rationale so far was that ‘guix lint foo’ should be fast (a couple
of seconds at most), and ‘guix lint’ (all packages) should complete in
less than a day.  ;-)

Thus, the ‘source’ and ‘home-page’ checks simply ensure that the URI
points to something accessible instead of actually downloading the
thing.  This is fast and catches the most obvious errors, but has the
drawback of not catching the right-URL-wrong-hash kind of errors.

Ludo’.

Re: ‘guix lint’ URL checks

[Leo Famulari]

On Sun, Aug 28, 2016 at 01:12:09AM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > I wonder, are there any drawbacks of making the linter check that the
> > URL provides the data named by the hash?
> 
> The rationale so far was that ‘guix lint foo’ should be fast (a couple
> of seconds at most), and ‘guix lint’ (all packages) should complete in
> less than a day.  ;-)

Reasonable :)

> Thus, the ‘source’ and ‘home-page’ checks simply ensure that the URI
> points to something accessible instead of actually downloading the
> thing.  This is fast and catches the most obvious errors, but has the
> drawback of not catching the right-URL-wrong-hash kind of errors.

I guess that `guix build --check --source foo` is the right way to check
for this mistake.