[PATCH] gnu: %bootstrap-coreutils&co: Patch egrep/fgrep to point to the correct grep.

  • Done
  • quality assurance status badge
Details
5 participants
  • Efraim Flashner
  • Jonathan Brielmaier
  • Ludovic Courtès
  • manolis837
  • zimoun
Owner
unassigned
Submitted by
manolis837
Severity
normal
Merged with
M
M
manolis837 wrote on 23 Feb 2017 12:41
(address . guix-patches@gnu.org)(address . efraim@flashner.co.il)
20170223114119.18004-1-manolis837@gmail.com
Hello everyone,

Commit 653add37af10b0d5dbc20c8bc7ce30eec8cf4ae7 patches egrep/fgrep to point to the location of grep.
But the problem is that when it was run on Hurd, the path for grep in egrep/fgrep had this form:
/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-grep-2.25/bin/grep

The above was not being substituted and caused the build to fail. So I changed the pattern to
"/[^ ]+/bin/grep" and now the path is always replaced.

Also (getcwd) returns the current path which the build takes place. This happens to be /tmp/guix-build-..-bootstrap-binaries-0.
This is wrong because it should point to the final place in /gnu/store. That why I am using "out".

Thank you,
Manolis
E
E
Efraim Flashner wrote on 25 Feb 2017 19:58
C634411A-54AB-496B-97CC-4C7D7FFF2BE2@flashner.co.il
On February 23, 2017 1:41:18 PM GMT+02:00, manolis837@gmail.com wrote:
Toggle quote (14 lines)
>
>Hello everyone,
>
>Commit 653add37af10b0d5dbc20c8bc7ce30eec8cf4ae7 patches egrep/fgrep to
>point to the location of grep.
>But the problem is that when it was run on Hurd, the path for grep in
>egrep/fgrep had this form:
>/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-grep-2.25/bin/grep
>
>The above was not being substituted and caused the build to fail. So I
>changed the pattern to
>"/[^ ]+/bin/grep" and now the path is always replaced.
>

I also pushed a patch that patched the generated [e|f]grep to not have the path inserted into it, so the aarch64 bootstrap binaries have:
#!/bin/sh
exec grep -F...
I think we're going to have to find a way that works for both architectures. I tried using (%current-target) but I couldn't get it to work inside the snippet.

Toggle quote (5 lines)
>Also (getcwd) returns the current path which the build takes place.
>This happens to be /tmp/guix-build-..-bootstrap-binaries-0.
>This is wrong because it should point to the final place in /gnu/store.
>That why I am using "out".

While that is probably better, in the end it doesn't really matter I believe, when I ran 'find /gnu -name fgrep -execdir cat {} +' it showed both bash and grep pointing to the bootstrap binaries.

Toggle quote (3 lines)
>Thank you,
>Manolis

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
L
L
Ludovic Courtès wrote on 26 Mar 2017 15:53
control message for bug #25849
(address . control@debbugs.gnu.org)
87tw6gp2kf.fsf@gnu.org
merge 25849 25848
J
J
Jonathan Brielmaier wrote on 16 Nov 2020 18:59
[PATCH] gnu: %bootstrap-coreutils
(address . 25848@debbugs.gnu.org)
62265294-3ea4-f72b-439d-0a207e5674da@web.de
@Manolis: Does this problem still exist with all the new Hurd work from
Janneke and Co?
Z
Z
zimoun wrote on 5 Jan 2022 00:57
Re: bug#25848: [PATCH] gnu: %bootstrap-coreutils&co: Patch egrep/fgrep to point to the correct grep.
(address . manolis837@gmail.com)
86o84r9hqy.fsf@gmail.com
Hi Manolis,

I am doing bug triage and I hit this one [1].



On Thu, 23 Feb 2017 at 13:41, manolis837@gmail.com wrote:

Toggle quote (10 lines)
> Commit 653add37af10b0d5dbc20c8bc7ce30eec8cf4ae7 patches egrep/fgrep to point to the location of grep.
> But the problem is that when it was run on Hurd, the path for grep in egrep/fgrep had this form:
> /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-grep-2.25/bin/grep
>
> The above was not being substituted and caused the build to fail. So I changed the pattern to
> "/[^ ]+/bin/grep" and now the path is always replaced.
>
> Also (getcwd) returns the current path which the build takes place. This happens to be /tmp/guix-build-..-bootstrap-binaries-0.
> This is wrong because it should point to the final place in /gnu/store. That why I am using "out".

Is it still relevant after the work by janneke among many others? And
exposed in these blog post [2,3].




Cheers,
simon
E
E
Efraim Flashner wrote on 5 Jan 2022 09:23
(name . zimoun)(address . zimon.toutoune@gmail.com)
YdVVdYxpBra1OHye@3900XT
On Wed, Jan 05, 2022 at 12:57:25AM +0100, zimoun wrote:
Toggle quote (27 lines)
> Hi Manolis,
>
> I am doing bug triage and I hit this one [1].
>
> 1: <http://issues.guix.gnu.org/issue/25848>
>
>
> On Thu, 23 Feb 2017 at 13:41, manolis837@gmail.com wrote:
>
> > Commit 653add37af10b0d5dbc20c8bc7ce30eec8cf4ae7 patches egrep/fgrep to point to the location of grep.
> > But the problem is that when it was run on Hurd, the path for grep in egrep/fgrep had this form:
> > /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-grep-2.25/bin/grep
> >
> > The above was not being substituted and caused the build to fail. So I changed the pattern to
> > "/[^ ]+/bin/grep" and now the path is always replaced.
> >
> > Also (getcwd) returns the current path which the build takes place. This happens to be /tmp/guix-build-..-bootstrap-binaries-0.
> > This is wrong because it should point to the final place in /gnu/store. That why I am using "out".
>
> Is it still relevant after the work by janneke among many others? And
> exposed in these blog post [2,3].
>
>
> 2: <https://guix.gnu.org/en/blog/2020/a-hello-world-virtual-machine-running-the-hurd/>
> 3: <https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes/>
>

Judging that the Hurd, aarch64 and powerpc are all have Guix working on
them I assume it's working well enough that we can close this bug.

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmHVVXIACgkQQarn3Mo9
g1Flmw/+MLijoz+1OOyWSZ2wLrQaRySpT6QxXzhcPUiukF86pw/W8eQeesfx3Hcq
7miTVA9cJJUbYzZ8ES5DWshPybMDkXQjskPtRqzGjepIGF3qR7/OnGJAg8g03Pki
moy6kqUkDVK8gewLaEfhm9FSvqXlZ4lq3V/NaezVWOL7e7oY9Il1G3H8lHuVbO2L
Zvxrgi+m8lAHRZ15cGEZS1zGwZQ/lwKMq2TjRT/Tj87PHUxZgcg6Cf3BDfliwy5/
uawxTUht/4Jpjr0fJ3sdsQ1qTTBF97S8lN84MywwcMVLw8+KXWLo6edrsfGUd6Ak
f8OeUd8V7OiOEM4Zlbc6B4g0m84UWzTtvHz5hlG20dpdcpwXre9XgxcYdDXJNoww
HCTVgihxp433tZPPxbP3BbpDI5cW0Rv05LdozUANMavG2CoNjVKp49iqyhjh0weP
wMNz/dOS0sR0BGYSsm0Nx9IvtrSnqO5+IEY0C2+R/2r7ZPAfhkYedVMw33ug2ptv
5SXUhDHTfcZ7xOTPqFy5qG1WiKEyybE5Q1yHWzP3JAUxYwwKJutR5E5sxkZmTILc
ajul1rf1f5cn89wS7a4JIDuLuWrCm+T/YoRl2ok1ZTev0NuVw/lYVwCp1dg/rAaq
vkKqbpOctKbHBolMlV7pi9Dlzp/+jRaNVtE93v0M4aP9H5C775Y=
=Qg8G
-----END PGP SIGNATURE-----


Z
Z
zimoun wrote on 5 Jan 2022 10:00
(name . Efraim Flashner)(address . efraim@flashner.co.il)
86pmp68sl5.fsf@gmail.com
Hi,

On Wed, 05 Jan 2022 at 10:23, Efraim Flashner <efraim@flashner.co.il> wrote:
Toggle quote (6 lines)
> On Wed, Jan 05, 2022 at 12:57:25AM +0100, zimoun wrote:
>> On Thu, 23 Feb 2017 at 13:41, manolis837@gmail.com wrote:

> Judging that the Hurd, aarch64 and powerpc are all have Guix working on
> them I assume it's working well enough that we can close this bug.

Therefore, I am closing.


Thanks,
simon
Closed
M
M
Manolis Ragkousis wrote on 5 Jan 2022 18:23
(name . zimoun)(address . zimon.toutoune@gmail.com)
CAFtzXzM2p=T9=H=2k=BztV4kMX=cTm4j8zfrs_2Ou3WFtVRoGQ@mail.gmail.com
Thank you, yes it can be closed.

On Wed, 5 Jan 2022, 11:11 zimoun, <zimon.toutoune@gmail.com> wrote:

Toggle quote (16 lines)
> Hi,
>
> On Wed, 05 Jan 2022 at 10:23, Efraim Flashner <efraim@flashner.co.il>
> wrote:
> > On Wed, Jan 05, 2022 at 12:57:25AM +0100, zimoun wrote:
> >> On Thu, 23 Feb 2017 at 13:41, manolis837@gmail.com wrote:
>
> > Judging that the Hurd, aarch64 and powerpc are all have Guix working on
> > them I assume it's working well enough that we can close this bug.
>
> Therefore, I am closing.
>
>
> Thanks,
> simon
>
Attachment: file
Closed
?
Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 25848
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