Ansible & others' problems with wrapped '.ansible-real' scripts

  • Done
  • quality assurance status badge
Details
6 participants
  • Arun Isaac
  • Brice Waegeneire
  • Danny Milosavljevic
  • Jelle Licht
  • Ludovic Courtès
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Jelle Licht
Severity
important
Merged with
Blocked by

Debbugs page

Jelle Licht wrote 8 years ago
(address . bug-guix@gnu.org)
CAPsKtfJKuf3CchsD0667ajg8bWSyp7YGTv8NU5qLf5kc7qEiHg@mail.gmail.com
Hi,

I had some problems getting current ansible package to work. It seems that
the bin/ansible script which is created as part of the python-build-system
via a call to `wrap-program' interferes with certain expectations ansible
has regarding how it and its subcommands are called.

This mechanism does not work well with our generated created .ansible-real.
See [1] for a similar issue that has since been worked around in the newest
version of ansible.

For now, I have a similar workaround that add some guix-specific checks to
ansible looking for being called as .ansible-real, though I do consider
this a hack. This problem is indicative of a bigger issue: the fact that
wrap-program currently leads to subtle bugs for lots of scripts. There has
been some noise on #guix about solving this problem in general.

Thanks,
Jelle

Attachment: file
Ludovic Courtès wrote 8 years ago
(name . Jelle Licht)(address . jlicht@fsfe.org)(address . 26752@debbugs.gnu.org)
874lx2w926.fsf@gnu.org
Jelle Licht <jlicht@fsfe.org> skribis:

Toggle quote (15 lines)
> I had some problems getting current ansible package to work. It seems that
> the bin/ansible script which is created as part of the python-build-system
> via a call to `wrap-program' interferes with certain expectations ansible
> has regarding how it and its subcommands are called.
>
> This mechanism does not work well with our generated created .ansible-real.
> See [1] for a similar issue that has since been worked around in the newest
> version of ansible.
>
> For now, I have a similar workaround that add some guix-specific checks to
> ansible looking for being called as .ansible-real, though I do consider
> this a hack. This problem is indicative of a bigger issue: the fact that
> wrap-program currently leads to subtle bugs for lots of scripts. There has
> been some noise on #guix about solving this problem in general.

For the record, the discussion is visible here:

I think it’s bad for a program to rely on argv[0], but I also think
those .thing-real are kinda ugly. :-)

Ludo’.
Ludovic Courtès wrote 8 years ago
control message for bug #26752
(address . control@debbugs.gnu.org)
87mv9vc447.fsf@gnu.org
severity 26752 important
Jelle Licht wrote 8 years ago
Re: bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 26752@debbugs.gnu.org)
CAPsKtfJ8rZ86RZiayXuZbYfeEUroAubvCsgKxZJDdg17Oijrnw@mail.gmail.com
The current ansible package is still brokenin the same way.

Is there already an acceptable way of working around this problem?
Otherwise I could send my (extremely hacky) workaround that adds a specific
condition in the ansible source code to check for .ansible-real.

Thanks,
Jelle

2017-05-03 12:04 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:

Toggle quote (31 lines)
> Jelle Licht <jlicht@fsfe.org> skribis:
>
> > I had some problems getting current ansible package to work. It seems
> that
> > the bin/ansible script which is created as part of the
> python-build-system
> > via a call to `wrap-program' interferes with certain expectations ansible
> > has regarding how it and its subcommands are called.
> >
> > This mechanism does not work well with our generated created
> .ansible-real.
> > See [1] for a similar issue that has since been worked around in the
> newest
> > version of ansible.
> >
> > For now, I have a similar workaround that add some guix-specific checks
> to
> > ansible looking for being called as .ansible-real, though I do consider
> > this a hack. This problem is indicative of a bigger issue: the fact that
> > wrap-program currently leads to subtle bugs for lots of scripts. There
> has
> > been some noise on #guix about solving this problem in general.
>
> For the record, the discussion is visible here:
> <https://gnunet.org/bot/log/guix/2017-05-02#T1370586>.
>
> I think it’s bad for a program to rely on argv[0], but I also think
> those .thing-real are kinda ugly. :-)
>
> Ludo’.
>
Attachment: file
Ludovic Courtès wrote 8 years ago
(name . Jelle Licht)(address . jlicht@fsfe.org)(address . 26752@debbugs.gnu.org)
8760fnsv3u.fsf@gnu.org
Hi,

Jelle Licht <jlicht@fsfe.org> skribis:

Toggle quote (6 lines)
> The current ansible package is still brokenin the same way.
>
> Is there already an acceptable way of working around this problem?
> Otherwise I could send my (extremely hacky) workaround that adds a specific
> condition in the ansible source code to check for .ansible-real.

For now I think we have to go with the hack. Make sure to add a comment
linking to this bug report.

Thanks,
Ludo’.
Ludovic Courtès wrote 7 years ago
control message for bug #26752
(address . control@debbugs.gnu.org)
87po2i56ke.fsf@gnu.org
merge 26752 31299
Ludovic Courtès wrote 7 years ago
Re: bug#31299: Ansible depends on $0, which does not work for wrapped python scripts.
(name . Jelle Licht)(address . jlicht@fsfe.org)
87h8nu56i1.fsf@gnu.org
Merging with https://bugs.gnu.org/26752, which you submitted a while
back.

Ludo’.
Danny Milosavljevic wrote 7 years ago
Re: bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts
(name . Jelle Licht)(address . jlicht@fsfe.org)(address . 26752@debbugs.gnu.org)
20180507192551.67cde93d@scratchpost.org
Just a heads-up, if we make the Python wrap-program do the wrapping inline (bug# 29856), this problem here will also vanish.

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

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlrwjB8ACgkQ5xo1VCww
uqUeIQf9EkZzE+LFUmbaX+WCodawzF1HhxWD56TB1sE25KUgKWCbLQBGpTjdabNZ
n6dMygxwlBJoILGCM6oimH8pcT1TmeiU+HPUBScDww4pVc+D2O+ze/N2aWqaEc4p
lJf5utGOdIx8HS3h+A7JbvCatoMlu3zKKvm0d86OvFbb7KFmMrqzJB4x8XshFucN
kTkewgTEvFWDS922a9Ow5GECs02qAj5VPH3WWMSpb8+LwQTVRbxjqBAk4qkqOxoz
cIU/Kf+LLBucC0jzi3eNe8y3o7W89nFJz4ZrxqTPO0hbeNbRS3BfmEWReI5gzwDE
g4pSa5XY2R7EInpzn09Lrz3PDbw6Pw==
=ladt
-----END PGP SIGNATURE-----


Ricardo Wurmus wrote 6 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)
87tvhkhu15.fsf@elephly.net
ludo@gnu.org (Ludovic Courtès) writes:
Toggle quote (11 lines)
> Jelle Licht <jlicht@fsfe.org> skribis:
>
>> The current ansible package is still brokenin the same way.
>>
>> Is there already an acceptable way of working around this problem?
>> Otherwise I could send my (extremely hacky) workaround that adds a specific
>> condition in the ansible source code to check for .ansible-real.
>
> For now I think we have to go with the hack. Make sure to add a comment
> linking to this bug report.

There is a way to get around this. It’s presented in #29951:


Open issues with this include a hard-coded store prefix, but it’s no big
obstacle. Should we give this a try on core-updates?
Ricardo Wurmus wrote 6 years ago
control message for bug #29951
(address . control@debbugs.gnu.org)
168b78834d7.67d54665800973180.6444581326634091821@zoho.com
block 29951 by 26752
Ricardo Wurmus wrote 6 years ago
control message for bug #26752
(address . control@debbugs.gnu.org)
168b80ff826.23c94323855229521.-827146741371564246@zoho.com
block 26752 by 29951
Arun Isaac wrote 6 years ago
Re: bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts
(name . Jelle Licht)(address . jlicht@fsfe.org)
cu77eefkfn7.fsf@systemreboot.net
Toggle quote (2 lines)
> The current ansible package is still brokenin the same way.

FWIW, I fixed our ansible package in
https://issues.guix.info/issue/33777. This is not a general solution,
but at least our ansible package works at the moment.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEf3MDQ/Lwnzx3v3nTLiXui2GAK7MFAlxYFMwACgkQLiXui2GA
K7Mk9Qf+NXoKhZIGeITnZh+eiVWH3RCZmqdNfqqAogNmOMYvYOM8TYxruGeCrRa+
o6IrfB+mdHSlzxIq60qwl/Y6CbZMpG1HebHNOrw+d9uqOmmmbbED47PllgWXezzx
DGxn2M+SxyUKwWJE7vbiy8vEMCm6eWGkVm73bjUZEkFh8+rrRWWmKt5bGkEy3W9l
Y4QhDbDphodCXCGx9T+vjcQYh+lnewEZ1QTaSQyHjrulkYFgRCzBijwt1gPP+4O4
yyu6XPwj4pE+AA1UsfHlBww1plIygbPvgadloizctUBIXWT+15ENIfL4WYpXAqQh
89vHn4vqrXWP2LWxlC/6p7tXxP4Kjw==
=IOdi
-----END PGP SIGNATURE-----

Ludovic Courtès wrote 6 years ago
(name . Ricardo Wurmus)(address . rekado@elephly.net)
8736p3sa2s.fsf@gnu.org
Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (19 lines)
> ludo@gnu.org (Ludovic Courtès) writes:
>> Jelle Licht <jlicht@fsfe.org> skribis:
>>
>>> The current ansible package is still brokenin the same way.
>>>
>>> Is there already an acceptable way of working around this problem?
>>> Otherwise I could send my (extremely hacky) workaround that adds a specific
>>> condition in the ansible source code to check for .ansible-real.
>>
>> For now I think we have to go with the hack. Make sure to add a comment
>> linking to this bug report.
>
> There is a way to get around this. It’s presented in #29951:
>
> https://issues.guix.info/issue/29951
>
> Open issues with this include a hard-coded store prefix, but it’s no big
> obstacle. Should we give this a try on core-updates?

Definitely, please do!

Thanks,
Ludo’.
Ludovic Courtès wrote 6 years ago
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87lg2s5zv7.fsf@gnu.org
Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (16 lines)
> ludo@gnu.org (Ludovic Courtès) writes:
>> Jelle Licht <jlicht@fsfe.org> skribis:
>>
>>> The current ansible package is still brokenin the same way.
>>>
>>> Is there already an acceptable way of working around this problem?
>>> Otherwise I could send my (extremely hacky) workaround that adds a specific
>>> condition in the ansible source code to check for .ansible-real.
>>
>> For now I think we have to go with the hack. Make sure to add a comment
>> linking to this bug report.
>
> There is a way to get around this. It’s presented in #29951:
>
> https://issues.guix.info/issue/29951

BTW, there’s also this patch series on this topic:


What to do?

Ludo’.
Brice Waegeneire wrote 5 years ago
(address . 26752@debbugs.gnu.org)
507e6445fa33cdf78510af1c0fbda307@waegenei.re
Hello,

Arun Isaac <arunisaac@systemreboot.net> writes:
Toggle quote (4 lines)
> FWIW, I fixed our ansible package in
> https://issues.guix.info/issue/33777 . This is not a general solution,
> but at least our ansible package works at the moment.

If this bug is about ansible malfunctioning then it should be closed,
Arun fixed it in 01cb4d47570c38812492bbc331b7b818e1b69fbb. I've tested
it myself successfully with the command from the IRC report[0] (linked
in the merged issue[2]).
On the other hand If it's about fixing it with the new wrap-script from
Ricardo I can send a patch, but the derivation will need guile as a new
input.


Brice.
Jelle Licht wrote 5 years ago
87mu89bcw8.fsf@jlicht.xyz
Hi

Brice Waegeneire <brice@waegenei.re> writes:

Toggle quote (15 lines)
> Hello,
>
> Arun Isaac <arunisaac@systemreboot.net> writes:
>> FWIW, I fixed our ansible package in
>> https://issues.guix.info/issue/33777 . This is not a general solution,
>> but at least our ansible package works at the moment.
>
> If this bug is about ansible malfunctioning then it should be closed,
> Arun fixed it in 01cb4d47570c38812492bbc331b7b818e1b69fbb. I've tested
> it myself successfully with the command from the IRC report[0] (linked
> in the merged issue[2]).
> On the other hand If it's about fixing it with the new wrap-script from
> Ricardo I can send a patch, but the derivation will need guile as a new
> input.

I would be okay with closing it, as ansible works fine right now. If the
current solution is deemed too brittle, or if the intent behind the new
wrap-script is that we use it everywhere we can, then not of course.

- Jelle
Brice Waegeneire wrote 5 years ago
Close 26752
(address . control@debbugs.gnu.org)
c5a700aee483c9d494fe91a64f5de6f2@waegenei.re
# Author agreed, nobody objected in 7 days
close 26752
quit
?
Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 26752
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
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help