* bug#37150: Erroneous uses of regex in the invokation of FIND-FILES
[not found] ` <87mug1ylg3.fsf@netris.org>
@ 2019-08-23 2:50 ` Alex Vong
2019-08-23 3:55 ` Alex Vong
0 siblings, 1 reply; 2+ messages in thread
From: Alex Vong @ 2019-08-23 2:50 UTC (permalink / raw)
To: 37150
[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]
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
https://lists.gnu.org/archive/html/guix-devel/2019-08/msg00149.html).
Mark H Weaver writes:
> 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
https://twitter.com/freedomhkg
https://twitter.com/stand_with_hk
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* bug#37150: Erroneous uses of regex in the invokation of FIND-FILES
2019-08-23 2:50 ` bug#37150: Erroneous uses of regex in the invokation of FIND-FILES Alex Vong
@ 2019-08-23 3:55 ` Alex Vong
0 siblings, 0 replies; 2+ messages in thread
From: Alex Vong @ 2019-08-23 3:55 UTC (permalink / raw)
To: 37150
[-- Attachment #1.1: Type: text/plain, Size: 360 bytes --]
Hello Mark,
>> 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").
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-gnu-delta-Fix-regex-in-the-invokation-of-find-files.patch --]
[-- Type: text/x-diff, Size: 1066 bytes --]
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(-)
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
[-- Attachment #1.3: Type: text/plain, Size: 1219 bytes --]
>> 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.
>> Thanks for looking into it.
>>
>> Best,
>> Mark
You're welcomed!
--
Stand with Hong Kong!
#Eye4HK #BoycottMulan
Alex
https://twitter.com/freedomhkg
https://twitter.com/stand_with_hk
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-08-23 3:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <864l29iki4.fsf@gmail.com>
[not found] ` <87mug1ylg3.fsf@netris.org>
2019-08-23 2:50 ` bug#37150: Erroneous uses of regex in the invokation of FIND-FILES Alex Vong
2019-08-23 3:55 ` Alex Vong
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).