From: Vagrant Cascadian <vagrant@debian.org>
To: guix-devel@gnu.org
Subject: default tar format for "make dist" and patch file length
Date: Mon, 15 Nov 2021 16:34:16 -0800 [thread overview]
Message-ID: <87sfvxhrav.fsf@ponder> (raw)
[-- Attachment #1: Type: text/plain, Size: 3556 bytes --]
When running "make dist", guix apparently uses a very old tar format
(presumably for maximal compatibility with tar implementations), which
has a hard limit of 99 characters.
For this reason, there is a guix lint check for filename lengths, but
there are quite a few lint warnings in guix master and
core-updates-frozen.
On guix master db5907138cbf9139e885fa4b3860d604aff0be9c, there appear to
be 14 such patches:
$ guix lint --checkers=patch-file-names | grep 'too long' | nl
1 gnu/packages/admin.scm:2669:2: debops@1.1.0:
debops-constants-for-external-program-names.patch: file name is too
long
2 gnu/packages/astronomy.scm:865:2: xplanet@1.3.1:
xplanet-1.3.1-libdisplay_DisplayOutput.cpp.patch: file name is too
long
3 gnu/packages/astronomy.scm:865:2: xplanet@1.3.1:
xplanet-1.3.1-xpUtil-Add2017LeapSecond.cpp.patch: file name is too
long
4 gnu/packages/geo.scm:312:2: libgeotiff@1.5.1:
libgeotiff-adapt-test-script-for-proj-6.2.patch: file name is too
long
5 gnu/packages/glib.scm:478:2: gobject-introspection@1.62.0:
gobject-introspection-absolute-shlib-path.patch: file name is too
long
6 gnu/packages/java.scm:9032:2:
java-tunnelvisionlabs-antlr4-runtime@4.7.4:
java-tunnelvisionlabs-antlr-code-too-large.patch: file
name is too long
7 gnu/packages/java.scm:8926:2:
java-tunnelvisionlabs-antlr4-runtime-annotations@4.7.4:
java-tunnelvisionlabs-antlr-code-too-large
.patch: file name is too long
8 gnu/packages/java.scm:13120:2: java-apache-ivy@2.4.0:
java-apache-ivy-port-to-latest-bouncycastle.patch: file name is too
long
9 gnu/packages/java.scm:9040:2:
java-tunnelvisionlabs-antlr4@4.7.4:
java-tunnelvisionlabs-antlr-code-too-large.patch: file name is
too long
10 gnu/packages/kde-frameworks.scm:3419:2: plasma-framework@5.70.1:
plasma-framework-fix-KF5PlasmaMacros.cmake.patch: file name is
too long
11 gnu/packages/llvm.scm:98:2: clang-runtime@3.9.1:
clang-runtime-3.9-libsanitizer-mode-field.patch: file name is too
long
12 gnu/packages/llvm.scm:852:4: clang-runtime@3.5.2:
clang-runtime-3.5-libsanitizer-mode-field.patch: file name is too
long
13 gnu/packages/llvm.scm:98:2: clang-runtime@3.7.1:
clang-runtime-3.8-libsanitizer-mode-field.patch: file name is too
long
14 gnu/packages/llvm.scm:98:2: clang-runtime@3.8.1:
clang-runtime-3.8-libsanitizer-mode-field.patch: file name is too long
Looks like a similar number of patches on core-updates-frozen, too,
probably mostly the same ones.
Luckily, the lint check is conservative and actually gives a bit of
wiggle-room, and none of these appear to break "make dist" from
generating a tarball at the moment, but there was one in
core-updates-frozen recently that did break "make dist" (fixed in
6cdf4e5bf230fdbe17e592c2ec74fb34dba70eb5).
Ideally, "guix lint" would be run and issues fixed before applying
patches ... !
Is it worth adding an inexpensive check to etc/git/pre-push that also
checks for file-length and fails to push due to this issue potentially
breaking "make dist"?
A different angle might be to actually use a different tar format:
https://www.gnu.org/software/tar/manual/html_section/Formats.html
I would guess "make dist" is using the tar "v7" format, based on the 99
character length limit for files. Most of the other formats have no file
length limit or a longer limit.
Well, thanks for following my rambling this far!
live well,
vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
next reply other threads:[~2021-11-16 0:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 0:34 Vagrant Cascadian [this message]
2021-11-17 11:32 ` default tar format for "make dist" and patch file length Ludovic Courtès
2021-11-17 22:39 ` Vagrant Cascadian
2021-11-17 23:49 ` Vagrant Cascadian
2021-11-19 14:54 ` Ludovic Courtès
2021-11-20 4:39 ` Philip McGrath
2021-11-20 5:21 ` Vagrant Cascadian
2021-11-24 21:27 ` Vagrant Cascadian
2021-11-22 2:03 ` Maxim Cournoyer
2021-11-22 11:31 ` Ludovic Courtès
2021-11-22 20:14 ` Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sfvxhrav.fsf@ponder \
--to=vagrant@debian.org \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).