Attila Lendvai schreef op wo 08-09-2021 om 09:20 [+0000]: > thanks for the ideas Maxime! > > > > You could patch trezor-agent with something like > > > > Python syntax might be incorrect > > ================================ > > > > if sys.argv[0] == ".trezor-gpg' > > sys.argv[0] = "trezor-gpg" > > device_name = os.path.basename(sys.argv[0]).rsplit('-',1)[0] > > > > Would that work? > > most probably, but i thought first i'll pursue a more general fix for > this. i will fall back to just patching upstream if i fail. > > > > FWIW, there's 'wrap-program' and there is 'wrap-script'. > > > > wrap-script is less likely to cause errors here (it doesn't rename the executable) > > but less general. Maybe wrap-script can be used instead of wrap-program? > > not sure how to do this. looking at python-build-system.scm it looks > like there is no way to tell it to use wrap-script, so i went ahead > and just changed the wrap-program call to wrap-script globally, and > gave it a try. Are you referring to the lines (for-each (lambda (dir) (let ((files (list-of-files dir))) (for-each (cut wrap-program <> var) files))) bindirs) in the procedure 'wrap' from (guix build python-build-system)? > the first error i encountered was in the package called scons. it has > .bat files that wrap-script fails on. if i delete them in a snippet, > then scons' own build system errors out. The .bat are only for Windows, so you could remove them after the 'install' phase or before the 'wrap' phase. They seem to be useless on GNU/{Linux,Hurd}. > any hints on how to proceed from here? Instead of modifying 'wrap', you could replace the 'wrap' phase with something like `(#:phases (modify-phases %standard-phases (replace 'wrap (lambda _ ... customised wrapping code ...)))) Also, replacing wrap-program with wrap-script globally won't work because wrap-script is less general, it only spports python, R, perl and bash. So something like (define (wrap-script-or-program ...) (if it-uses-python-or-ruby-or... (wrap-script ...) (wrap-program ...))) may be required. > was this what you meant at all? > > would it be a worthwhile improvement to hack my way through this path > at all? There were some changes on core-updates to reduce double-wrapping, so possibly it's already solved. > shall i try to make it configurable from the package's definition, > change the default, and force it back to wrap-program for packages > that fail with wrap-script? Perhaps try something like 'wrap-script-or-program' first? That should reduce the number of package definitions that need to be adjusted. Greetings, Maxime.