Erroneous uses of regex in the invokation of FIND-FILES

  • Open
  • quality assurance status badge
Details
One participant
  • Alex Vong
Owner
unassigned
Submitted by
Alex Vong
Severity
normal
A
A
Alex Vong wrote on 23 Aug 2019 04:50
(address . bug-guix@gnu.org)
861rxcioit.fsf@gmail.com
Hello guix,

Currently, there are a lot of erroneous uses of regex in the invokation
of FIND-FILES. Please see the conversations below (taken from

Mark H Weaver writes:

Toggle quote (51 lines)
> Hi Alex,
>
> Alex Vong <alexvong1995@gmail.com> writes:
>
>> I find out that there are a lof of erroneous uses of regex in the
>> invokation of FIND-FILES. The correct usage should be:
>>
>> (find-files "." "\\.c$")
>>
>> Instead people write:
>>
>> (find-files "." ".*\\.c")
>>
>> which match unwanted files.
>>
>> For examples, in the procedure CUSTOM-GCC, the correct regex should be:
>>
>> "(c\\+\\+|cpp|g\\+\\+|gcov|gcc|gcc-.*)$"
>>
>> instead of:
>>
>> ".*(c\\+\\+|cpp|g\\+\\+|gcov|gcc|gcc-.*)"
>>
>> Please correct me if I am wrong.
>
> You're right. It would be good to fix these problems incrementally, as
> long as the changes don't cause too many rebuilds.
>
> Changes to core packages will need to wait for now, since 'core-updates'
> is frozen, and 'core-updates-next' should also be considered frozen,
> since it will become 'core-updates' as soon as Berlin has built it out a
> bit more. (The only change in 'core-updates-next' relative to
> 'core-updates' is that the new bootstrap tarballs have been fixed to be
> deterministic.)
>
> For some of these fixes, it might be best to apply them to 'staging'.
>
>> Right now, the erroneous use of regex in CUSTOM-GCC casues the 'bin/'
>> directory of the output of gccgo, gcc-objc and gcc-objc++ to be empty.
>
> I'm uncertain how many rebuilds it would trigger to change 'custom-gcc',
> and I don't have confidence that "guix refresh -l" is capable of giving
> us a reliable answer. In the meantime, would you like to file a bug
> report for this, so it's not forgotten?
>
> Thanks for looking into it.
>
> Best,
> Mark


--
Stand with Hong Kong!
#Eye4HK
Alex

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQQwb8uPLAHCXSnTBVZh71Au9gJS8gUCXV9UWgAKCRBh71Au9gJS
8kCUAQCllDPx3sygAoAI2qJv74Dz6fKvF9FNh+j+WfJ+p/T9UAEA9CU9RJSp/0DA
SxHDGeHMcetMoj9nkgQq8AZPTrjaAgc=
=fvZ/
-----END PGP SIGNATURE-----

A
A
Alex Vong wrote on 23 Aug 2019 05:55
(address . 37150@debbugs.gnu.org)(name . Mark H Weaver)(address . mhw@netris.org)
86zhk0h6y3.fsf@gmail.com
Hello Mark,

Toggle quote (3 lines)
>> You're right. It would be good to fix these problems incrementally, as
>> long as the changes don't cause too many rebuilds.
>>
I agree we should fix it incrementally, like how the 'invoke' transition
was handled. The patch below does exactly that (it fixes the problem for
delta which causes 6 rebuilds only according to "guix refresh -l").
From cb5f2febd564a2bcb550de537156db59588098c4 Mon Sep 17 00:00:00 2001
From: Alex Vong <alexvong1995@gmail.com>
Date: Fri, 23 Aug 2019 11:06:49 +0800
Subject: [PATCH] gnu: delta: Fix regex in the invokation of 'find-files'.

See https://bugs.gnu.org/37150 for more information.

* gnu/packages/debug.scm (delta)[arguments]: Fix regex.
---
gnu/packages/debug.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Toggle diff (15 lines)
diff --git a/gnu/packages/debug.scm b/gnu/packages/debug.scm
index 82631deef6..e1cba5d3fe 100644
--- a/gnu/packages/debug.scm
+++ b/gnu/packages/debug.scm
@@ -75,7 +75,7 @@
(begin
(for-each (lambda (h)
(install-file h doc))
- `("License.txt" ,@(find-files "www" ".*\\.html")))
+ `("License.txt" ,@(find-files "www" "\\.html$")))
(for-each (lambda (b)
(install-file b bin))
`("delta" "multidelta" "topformflat"))))
--
2.23.0
Toggle quote (17 lines)
>> Changes to core packages will need to wait for now, since 'core-updates'
>> is frozen, and 'core-updates-next' should also be considered frozen,
>> since it will become 'core-updates' as soon as Berlin has built it out a
>> bit more. (The only change in 'core-updates-next' relative to
>> 'core-updates' is that the new bootstrap tarballs have been fixed to be
>> deterministic.)
>>
>> For some of these fixes, it might be best to apply them to 'staging'.
>>
>>> Right now, the erroneous use of regex in CUSTOM-GCC casues the 'bin/'
>>> directory of the output of gccgo, gcc-objc and gcc-objc++ to be empty.
>>
>> I'm uncertain how many rebuilds it would trigger to change 'custom-gcc',
>> and I don't have confidence that "guix refresh -l" is capable of giving
>> us a reliable answer. In the meantime, would you like to file a bug
>> report for this, so it's not forgotten?
>>
It would probably cause a world rebuild... I will wait for the next
cycle for patch submittion.

Toggle quote (5 lines)
>> Thanks for looking into it.
>>
>> Best,
>> Mark

You're welcomed!


--
Stand with Hong Kong!
#Eye4HK #BoycottMulan
Alex

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQQwb8uPLAHCXSnTBVZh71Au9gJS8gUCXV9jlAAKCRBh71Au9gJS
8m0xAP9eWbx+nuJ7TlmIUiinZA//diChWzWivt0ay23kR806tQD+LuqLxadqBzgo
NE5rZb0DbRkdhmQoF5MVdJ8+4bdq0Qw=
=8hgq
-----END PGP SIGNATURE-----

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 37150@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 37150
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch