From: ludo@gnu.org (Ludovic Courtès)
To: Arun Isaac <arunisaac@systemreboot.net>
Cc: 32102@debbugs.gnu.org, "Clément Lassieur" <clement@lassieur.org>
Subject: [bug#32102] [PATCH v2 2/2] gnu: gajim: Combine wrap-program phases.
Date: Mon, 27 Aug 2018 13:37:13 +0200 [thread overview]
Message-ID: <87mut8avme.fsf@gnu.org> (raw)
In-Reply-To: <cu7tvohd0pn.fsf@systemreboot.net> (Arun Isaac's message of "Mon, 30 Jul 2018 06:00:28 +0530")
Hi Arun,
Sorry for the delay.
Arun Isaac <arunisaac@systemreboot.net> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
>
>>> From 6ee5cf4423109ab64df58c85f4114e456dda098b Mon Sep 17 00:00:00 2001
>>> From: Arun Isaac <arunisaac@systemreboot.net>
>>> Date: Wed, 11 Jul 2018 13:03:33 +0530
>>> Subject: [PATCH v3 1/3] build-system: python: Do not double wrap executables.
>>> To: clement@lassieur.org
>>> Cc: mhw@netris.org,
>>> andreas@enge.fr,
>>> 32102@debbugs.gnu.org
>>
>> Hmm, weird!
>
> What's weird? Are you referring to the Cc field? The people in the Cc
> field were originally referred to by Clement. So, I put them there to
> keep them in the loop.
Yes that makes perfect sense. Sorry for the obscure comment on my side;
I was just surprised to see a Cc: header like this in the patch itself,
but it’s nothing special after all.
>>> (define* (wrap #:key inputs outputs #:allow-other-keys)
>>> (define (list-of-files dir)
>>> - (map (cut string-append dir "/" <>)
>>> - (or (scandir dir (lambda (f)
>>> - (let ((s (stat (string-append dir "/" f))))
>>> - (eq? 'regular (stat:type s)))))
>>> - '())))
>>> + (find-files dir (lambda (file stat)
>>> + (and (eq? 'regular (stat:type stat))
>>> + (not (is-wrapped? file))))))
>>
>> Something I don’t get is that ‘wrap-program’ itself is supposed to
>> detect already-wrapped program. I vaguely remember discussing it before
>> but I forgot what the conclusions were; do we really need extra
>> ‘wrapped?’ checks? Can’t we fix ‘wrap-program’ itself?
>
> Could you refer to our earlier discussion on 32102?
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32102
>
> In the case of Gajim, our current wrapping ends up double wrapping and
> creating bin/.gajim-real-real. The original fix I proposed was to modify
> `wrap-program` to fix already-wrapped detection. But, after discussion
> with Clement, we decided to go with a is-wrapped? check in the python
> build system. Do check out our earlier discussion and let us know what
> you think.
Right. I re-read it and it’s all clear again. :-) The issue is that
‘list-of-files’ in the ‘wrap’ phase of python-build-system would pick up
files that are themselves wrappers already.
Because of my slow reaction we missed the train of this ‘core-updates’
cycle. :-/ So I think it’ll have to be for next time. Sounds good?
Let’s not forget about it…
Thank you,
Ludo’.
next prev parent reply other threads:[~2018-08-27 11:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 1:31 [bug#32102] [PATCH] utils: Fix wrap-program filename generation Arun Isaac
2018-07-09 7:35 ` Clément Lassieur
2018-07-09 10:49 ` Arun Isaac
2018-07-09 14:12 ` Clément Lassieur
2018-07-10 5:16 ` Arun Isaac
2018-07-10 8:57 ` Clément Lassieur
2018-07-10 18:13 ` Mark H Weaver
2018-07-11 19:26 ` [bug#32102] [PATCH v2 0/2] build-system: python: Only wrap non-hidden executable files Arun Isaac
2018-07-11 19:26 ` [bug#32102] [PATCH v2 1/2] " Arun Isaac
2018-07-13 7:42 ` Clément Lassieur
2018-07-13 8:35 ` Arun Isaac
2018-07-11 19:26 ` [bug#32102] [PATCH v2 2/2] gnu: gajim: Combine wrap-program phases Arun Isaac
2018-07-13 8:38 ` Clément Lassieur
2018-07-13 9:45 ` Arun Isaac
2018-07-28 20:42 ` Arun Isaac
2018-07-29 14:20 ` Ludovic Courtès
2018-07-30 0:30 ` Arun Isaac
2018-08-27 11:37 ` Ludovic Courtès [this message]
2018-08-28 8:37 ` Arun Isaac
2018-08-29 20:42 ` Ludovic Courtès
2018-11-22 16:54 ` Arun Isaac
2018-11-23 9:09 ` Ludovic Courtès
2018-11-27 10:43 ` bug#32102: " Arun Isaac
2018-11-27 12:24 ` [bug#32102] " Clément Lassieur
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mut8avme.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=32102@debbugs.gnu.org \
--cc=arunisaac@systemreboot.net \
--cc=clement@lassieur.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.