Re: branch master updated: gnu: gnuradio: Fix runtime python environment for plugins.
Hi,
Ludovic Courtès skribis:
> Hi Guillaume,
>
> guix-comm...@gnu.org skribis:
>
>> (native-search-paths
>> + ;; Variables required to find third-party plugins at runtime.
>> (list (search-path-specification
>> (variable "GRC_BLOCKS_PATH")
>> -(files '("/share/gnuradio/grc/blocks")
>> +(files '("share/gnuradio/grc/blocks")))
>> + (search-path-specification
>> +(variable "PYTHONPATH")
>> +(files (list (string-append "lib/python"
>> +(version-major+minor
>> + (package-version python))
>> +"/site-packages"))
>> (synopsis "Toolkit for software-defined radios")
>
> It’s not OK to have PYTHONPATH in here because that variable “belongs”
> to Python, not to GNU Radio.
>
> A profile containing both gnuradio and python will have PYTHONPATH
> correctly set. However, I guess you want to ensure that PYTHONPATH is
> correct even when Python is not in the profile, right?
>
> In that case, I’d recommend wrapping the gnuradio executables such that
> PYTHONPATH is correct.
>
> Does that make sense?
>
> See also one of our oldest bugs: .
>
> (Apologies if I missed a previous discussion!)
>
> Thanks,
> Ludo’.
The gnuradio-companion program generates a Python script based on the
user's flowchart of signal processing blocks, and then executes it.
Some extra "gnuradio blocks" can be added as plugin, like the
gnuradio-osmosdr and gnuradio-iqbalance packages. For the Python script
to be able to import the plugins installed in the Guix profile (or Guix
environment), the PYTHONPATH variable must be defined in the profile (or
environment).
I got the idea of putting PYTHONPATH in native-search-paths from the
Gajim package. I guess it will have to be fixed as well.
What would be the best way to have PYTHONPATH set to the runtime profile
or environment without putting it in native-search-paths?
- Make python a native-input?
- Wrap binaries with
"PYTHONPATH=$GUIX_ENVIRONMENT/lib/python/3.7/site-packages:$GUIX_PROFILE/lib/python/3.7/site-packages:$PYTHONPATH"?
- Something else?
signature.asc
Description: PGP signature
Re: M2-Planet v1.6.0 and mescc-tools v1.0.0 released
On Sat, May 02, 2020 at 08:58:47AM +0200, Jan Nieuwenhuizen wrote: > > A K+R C equivalent C compiler, assembler, linker, dwarf stub generator > > and shell able to produce fully standards compliant ELF binaries for > > Knight, x86, AMD64, armv7l and aarch64 and be bootstrapped from a sub > > 250byte hex0 hex assembler and a 737byte shell > Congratulations on this beautiful release; an amazing piece of work! indeed! applause for reaching v1.0.0! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: [PATCH] website: Update sjd.se servers.
Simon Josefsson writes: > * website/apps/base/templates/donate.scm (donate-t): I've pushed this patch now: https://guix.gnu.org/donate/ Thank you! signature.asc Description: PGP signature
Re: [bug#39825] [PATCH] gnu: Add warsow-qfusion.
Somehow this issue went away by itself. I've fixed added sound support to the package definition. Merged with 39f1806ca1d04b9aee70e897e06466aadbbee152. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: branch master updated: gnu: Add warsow-qfusion.
Hi Pierre,
guix-comm...@gnu.org writes:
> commit 39f1806ca1d04b9aee70e897e06466aadbbee152
> Author: Pierre Neidhardt
> AuthorDate: Thu Apr 9 15:56:42 2020 +0200
>
> gnu: Add warsow-qfusion.
>
> * gnu/local.mk (warsow-qfusion): New variable.
This commit message is weird.
> ---
> gnu/local.mk | 1 +
> gnu/packages/game-development.scm | 78
> +++
> 2 files changed, 79 insertions(+)
warsow-qfusion-fix-bool-return-type.patch is missing, breaking the
build of both Guix and this package.
> +(define-public warsow-qfusion
> + ;; As of 2020-04-09, the latest stable version 2.1.0 is deprecated.
> + ;; The 2.5 beta as published on the homepage is commit
> + ;; c4de15df559410aff0ca6643724e24cddb0ecbbd
> + (let ((commit "c4de15df559410aff0ca6643724e24cddb0ecbbd")
> +(arch (match (or (%current-target-system)
> + (%current-system))
> +("x86_64-linux" "x86_64")
> +("i686-linux" "i386")
> +(_ ""
Don't do this if you just need to determine architecture at build time.
> + (add-after 'install 'really-install
> + (lambda* (#:key outputs #:allow-other-keys)
> + (let ((out (assoc-ref outputs "out")))
> + (install-file (string-append
> "../source/build/basewsw/libgame_"
> + ,arch ".so")
> + (string-append out "/lib/"))
> + (install-file (string-append "../source/build/libui_" ,arch
> ".so")
> + (string-append out "/lib/"))
Add it here instead. There is also no need for the fallback value
as the package apparently only supports i686 and x86_64 according to
supported-systems.
> + (synopsis "Warsow's fork of qfusion, the id Tech 2 derived game
> engine")
> + (supported-systems '("i686-linux" "x86_64-linux"))
> + (description
> + "This package contains Warsow's fork of qfusion, the id Tech 2 derived
> +game engine. id Tech 2 is the engine originally behind Quake 2.")
> + (license license:gpl2+
Nit-pick: could you put description immediately after synopsis? Also,
please avoid restating the synopsis in the description, but try to
expand on it. I.e. what is Warsow? I thought it was a city!
Meanwhile I've reverted the commit so that 'make' works again.
Thanks!
signature.asc
Description: PGP signature
Re: branch master updated: gnu: Add warsow-qfusion.
Pierre Neidhardt writes:
> Hi Marius,
>
> Sorry, I rebased and edited a few things, some changes slipped through
> and resulted in this terrible commit :(
>
>> + (let ((commit "c4de15df559410aff0ca6643724e24cddb0ecbbd")
>> +(arch (match (or (%current-target-system)
>> + (%current-system))
>> +("x86_64-linux" "x86_64")
>> +("i686-linux" "i386")
>> +(_ ""
>> Don't do this if you just need to determine architecture at build time.
>
> Just to be sure, you suggest moving this inside the 'really-install
> phase, right?
Yes. Otherwise it gets needlessly evaluated by the Guix "front-end"
every time one uses 'guix search' etc -- even on unsupported
architectures. It's better to do it at build time, especially when it
is only used within a single phase.
On a related note, the 'ccl' package has a similar issue, and actually
produces an invalid derivation on aarch64 and armhf. It can be seen by
running e.g. 'guix weather -s armhf-linux'. I've been meaning to file a
bug about it forever, but typically just comment the package and forget
about it. :-/
signature.asc
Description: PGP signature
Re: branch master updated: gnu: Add warsow-qfusion.
Marius Bakke writes: > On a related note, the 'ccl' package has a similar issue, and actually > produces an invalid derivation on aarch64 and armhf. It can be seen by > running e.g. 'guix weather -s armhf-linux'. I've been meaning to file a > bug about it forever, but typically just comment the package and forget > about it. :-/ I don't understand why the `ccl' package would have an invalid derivation on armhf-linux: All `match' seem to be correct, but I can't test at the moment. Are you sure this is a similar issue? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: branch master updated: gnu: Add warsow-qfusion.
Marius Bakke writes:
>>> + (let ((commit "c4de15df559410aff0ca6643724e24cddb0ecbbd")
>>> +(arch (match (or (%current-target-system)
>>> + (%current-system))
>>> +("x86_64-linux" "x86_64")
>>> +("i686-linux" "i386")
>>> +(_ ""
>>> Don't do this if you just need to determine architecture at build time.
>>
>> Just to be sure, you suggest moving this inside the 'really-install
>> phase, right?
>
> Yes. Otherwise it gets needlessly evaluated by the Guix "front-end"
> every time one uses 'guix search' etc -- even on unsupported
> architectures. It's better to do it at build time, especially when it
> is only used within a single phase.
I don't understand the difference.
(match (or (%current-target-system)
(%current-system))
("x86_64-linux" "x86_64")
("i686-linux" "i386"))
must be unquoted inside the phase, so it's evaluated when the package
is and not at build time, isn't it?
Else how do you match against the build architecture at build time?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Re: core-updates call for testing
Marius Bakke writes: > Please try upgrading your profiles and systems and file bugs for > anything that does not work for you. GNOME users in particular are > encouraged to try the new GNOME 3.34 and report any regressions. I did some testing today, I managed to upgrade my profile after I excluded flightgear, hplip and unknown-horizons (this fails to build on master as well). I've got a patch to fix python-s3transfer [1]. 1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41027 As for reconfiguring my system, I use hplip with the CUPS service, so that doesn't work. I did have a look at hplip but I got lost in the configure script. I did find something related to Fedora [2]. 2: https://bugzilla.redhat.com/show_bug.cgi?id=1706233 3: https://src.fedoraproject.org/rpms/hplip/c/2268f0b1bdc4abce391458a5c90500d37ed438b6?branch=master The other issue I ran in to when trying to build my system was the channel/inferior I use for Linux didn't work. I've raised [4] regarding this. 4: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41028 Thanks, Chris signature.asc Description: PGP signature
Re: Network services in ‘guix system docker-image’?
Ludovic Courtès writes: > Does it make any sense at all to have things like a DHCP client and nscd > inside a Docker image produced by ‘guix system docker-image’? > > I was going to apply the patch below to allow users to get rid of these > services by running ‘guix system docker-image --network’. But now, I’m > wondering if there’s a use case to have them at all. > > Thoughts? I'm very unsure, but I don't think they'd be normally useful to include. Making it an option is also fine though. Thanks, Chris signature.asc Description: PGP signature
Exact same 'call-with-temporary-directory' defined twice?
Dear, The exact same function named 'call-with-temporary-directory' is defined in the 2 files: - guix/utils.scm - guix/swh.scm Please, could you explain what is the motivation? CIrcular dependencies? The comment in guix/swh.scm says ';FIXME: factorize'. Does it means: move it in the file 'guix/utils.scm'? Best regards, simon
Re: Bump stackage LTS
Hi, Timothy Sample writes: > AFAIK, we are OK to use the wip-haskell branch. I will reset it to > master and get started today or tomorrow. I just pushed GHC 8.8 to wip-haskell-updates, which I reset to core-updates. (I’m betting that core-updates will be merged before the Haskell updates are finished.) Next I’ll start updating the package versions for Stackage LTS 15. -- Tim
