bug#45193: Wrapper of Qt programs doesn't extend existing environment variable
Reproduce steps: guix environment --ad-hoc qbittorrent && cat $GUIX_ENVIRONMENT/bin/qbittorrent We can see the wrapper generated in qt-build-system doesn't extend existing environment variable. Instead, it overrides them. It was discussed in https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00117.html one year ago. This's not a trivial issue because using input method in Qt program requires an qt plugin(XIM doesn't work here) which is managed by QT_PLUGIN_PATH. We should change following functions: 1. guix/build/qt-build-system.scm(wrap-all-programs) 2. guix/build/qt-utils.scm(wrap-qt-program) It's ideal to make wrap-all-programs use wrap-qt-program internally and we don't need to maintain two copy of wrap code. -- Retrieve my PGP public key: https://meta.sr.ht/~citreu.pgp Zihao signature.asc Description: PGP signature
bug#45193: Acknowledgement (Wrapper of Qt programs doesn't extend existing environment variable)
In guix/build/qt-utils.scm:24:11
(define (wrap-qt-program out program)
(define (suffix env-var path)
^
I can't understand this, if you want to do a suffix wrap, you
should do it in "wrap-program"(e.g. `("XDG_DATA_DIRS" suffix
(,vars))), it will generate bash codes to do the job. If you
use Guile code here, it'll capture build time environment
variable values.
--
Retrieve my PGP public key: https://meta.sr.ht/~citreu.pgp
Zihao
signature.asc
Description: PGP signature
bug#45196: guile-studio cannot open file
Hi! These two commands reproduce an error in guile-studio/emacs, which prevents it from opening the file argument: stefan@guix ~/development/guix$ guix environment --pure --ad-hoc guile-studio stefan@guix ~/development/guix [env]$ guile-studio README This is the error in emacs’ Messages buffer: Loading /gnu/store/2z03mc1hyq8ii0w7n5ggwf4j5qb8kfyq-emacs-27.1/share/emacs/site-lisp/guix-emacs.el (source)...done eval-buffer: Cannot open load file: No such file or directory, company The passed file README will not be opened. Bye Stefan
bug#45202: pcscd service (pcsc-lite) doesn't handle run directory properly
Hi,
I use the pcsc-lite package and noticed that the pcscd service is
sometimes not started by shepherd/herd. If it is started, "herd start
pcscd" gives me the following error message (sorry for the german part):
> herd: Ausnahmefehler während der Ausführung von »start« mit dem Dienst
> »pcscd«:
> In procedure open-file: No such file or directory: "/var/run/pcscd/pcscd.pid"
The reason seems to be that pcsc-lite creates its pid file in
"/run/pcscd/", but herd expects it in "/var/run/pcscd/". This leads to
the service not being started when the files in "/run/pcscd/" have not
been cleaned up (or so my interpretation). In this case, I get the
error message:
> herd: Ausnahmefehler während der Ausführung von »start« mit dem Dienst
> »pcscd«:
> Throw to key `%exception' with args `("#<&invoke-error program:
> \"/gnu/store/r1yd6czv3r0is0a1gfsrix3gslkba80v-pcsc-lite-1.9.0/sbin/pcscd\"
> arguments: () exit-status: 1 term-signal: #f stop-signal: #f>")'.
If I delete the "/run/pcscd" directory, the daemon will be started,
although with the first error message from above.
I have been using guix for only a week now and don't know how to edit
service definitions etc., but maybe someone more competent could have a
look at this.
Regards,
Raffael
bug#45202: pcscd service (pcsc-lite) doesn't handle run directory properly
Raffael, Raffael Stocker 写道： The reason seems to be that pcsc-lite creates its pid file in "/run/pcscd/", but herd expects it in "/var/run/pcscd/". Thanks for the report! I'm closing this bug because I believe to've fixed it on master. Pull it and see. /var/run has no place on modern GNU/Linux. We should strive to migrate all remaining users to /run, but there's no rush. Kind regards, T G-R signature.asc Description: PGP signature
