* More checks for Makefile.am:assert-no-store-file-names ?
@ 2020-09-07 23:07 Vagrant Cascadian
2020-09-16 10:27 ` Ludovic Courtès
0 siblings, 1 reply; 2+ messages in thread
From: Vagrant Cascadian @ 2020-09-07 23:07 UTC (permalink / raw)
To: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]
When running "make dist" there are some checks run, such as checking for
hard-coded store paths.
Would it be a good idea to add this or a similar check to
etc/git/pre-push and/or guix lint?
Would it make sense to set up a job to run "make dist" on the build farm
to catch these problems?
# Make sure we're not shipping a file that embeds a local /gnu/store file name.
assert-no-store-file-names:
$(AM_V_at)if grep -r --exclude=*.texi --exclude=*.info \
--exclude=*.info-[0-9] --exclude=*.dot \
--exclude=*.eps --exclude-dir=bootstrap \
--exclude=guix-manual.pot --exclude=guix-manual.*.po \
--exclude=guix-cookbook.pot --exclude=guix-cookbook.*.po \
--exclude=guix-prettify.el \
--exclude=ChangeLog* \
--exclude=binutils-boot-2.20*.patch \
-E "$(storedir)/[a-z0-9]{32}-" $(distdir) ; \
then \
echo "error: store file names embedded in the distribution" >&2 ; \
exit 1 ; \
fi
Checking this more often could prevent:
bug#43005: make dist fails: "store file names embedded in the distribution"
It would be nice to catch these bugs earlier, especially when they are
low down on dependency chain!
live well,
vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: More checks for Makefile.am:assert-no-store-file-names ?
2020-09-07 23:07 More checks for Makefile.am:assert-no-store-file-names ? Vagrant Cascadian
@ 2020-09-16 10:27 ` Ludovic Courtès
0 siblings, 0 replies; 2+ messages in thread
From: Ludovic Courtès @ 2020-09-16 10:27 UTC (permalink / raw)
To: Vagrant Cascadian; +Cc: guix-devel
Hi!
Vagrant Cascadian <vagrant@debian.org> skribis:
> When running "make dist" there are some checks run, such as checking for
> hard-coded store paths.
>
> Would it be a good idea to add this or a similar check to
> etc/git/pre-push and/or guix lint?
>
> Would it make sense to set up a job to run "make dist" on the build farm
> to catch these problems?
>
> # Make sure we're not shipping a file that embeds a local /gnu/store file name.
> assert-no-store-file-names:
> $(AM_V_at)if grep -r --exclude=*.texi --exclude=*.info \
> --exclude=*.info-[0-9] --exclude=*.dot \
> --exclude=*.eps --exclude-dir=bootstrap \
> --exclude=guix-manual.pot --exclude=guix-manual.*.po \
> --exclude=guix-cookbook.pot --exclude=guix-cookbook.*.po \
> --exclude=guix-prettify.el \
> --exclude=ChangeLog* \
> --exclude=binutils-boot-2.20*.patch \
> -E "$(storedir)/[a-z0-9]{32}-" $(distdir) ; \
> then \
> echo "error: store file names embedded in the distribution" >&2 ; \
> exit 1 ; \
> fi
>
> Checking this more often could prevent:
>
> bug#43005: make dist fails: "store file names embedded in the distribution"
>
> It would be nice to catch these bugs earlier, especially when they are
> low down on dependency chain!
This one was a bit of unusual case but yeah, it’d be nice to catch
earlier anyway. I’m not sure where to test it though: ‘guix lint’ would
miss some of the other issues, and a plain makefile rule might see too
much.
Probably the best thing to do is a “make dist” job under continuous
integration, as you suggest.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-09-16 10:27 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-07 23:07 More checks for Makefile.am:assert-no-store-file-names ? Vagrant Cascadian
2020-09-16 10:27 ` Ludovic Courtès
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).