[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43738: Patch file names too long
|
From: |
Brett Gilio |
|
Subject: |
bug#43738: Patch file names too long |
|
Date: |
Thu, 01 Oct 2020 21:36:44 -0500 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Ludovic Courtès <ludo@gnu.org> writes:
> There are several patch file names that are too long for ‘tar’, as
> reported during ‘make dist’:
>
> tar:
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/ocaml-bisect-fix-camlp4-in-another-directory.patch
> dosiernomo tro longas (maks 99); ne ŝutita
> tar:
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/audiofile-signature-of-multiplyCheckOverflow.patch
> dosiernomo tro longas (maks 99); ne ŝutita
> tar:
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/python2-pygobject-2-gi-info-type-error-domain.patch
> dosiernomo tro longas (maks 99); ne ŝutita
> tar:
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/audiofile-division-by-zero-BlockCodec-runPull.patch
> dosiernomo tro longas (maks 99); ne ŝutita
> tar:
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/python-robotframework-honor-source-date-epoch.patch
> dosiernomo tro longas (maks 99); ne ŝutita
>
> ‘guix lint’ reports it as well, but apparently this is easily
> overlooked.
>
> Ludo’.
Does it matter that this is coming from a dirty working tree? Maybe not.
Brett Gilio