Re: Packaging FreeCAD
Hi all, I have some more news on FreeCAD. - I responded to two tickets in two coin repos that will be needed to update coin and Pivy: + ticket on soqt: https://bitbucket.org/Coin3D/soqt/issues/6/wrong-path-for-soqt_library_dirs + ticket on coin: https://bitbucket.org/Coin3D/coin/issues/175/coin-build-errors-with-linux-and-osx - FreeCAD is compiling, but there is an install-phase error involving the Salome library SMESH. FreeCAD bundles smesh and a couple other libraries in the source. I inquired on their forum and have a few steps I can try this week. + I would like to use FreeCAD’s versions if possible. What is our stance on using bundled libraries? + Advantages of using the SMESH bundled with FreeCAD include not needing to package the various Salome libraries needed to compile SMESH. Some of those transitive dependencies include omniORB and opencascade itself. I spent a lot of this weekend trying to package SMESH and I came to realize that if we were to package it, we would need to also package opencascade-occt and we would not be able to use oce which we have already. Thanks for your patience on this. As always, my work is available on master at https://github.com/jsoo1/guix-channel. Thanks for your patience on this one. It has been a long and instructive exercise. I will be on vacation the coming two weeks, so I won’t be able to work on it. I know it’s already been months, now and I hope it can be done in maybe two more. Hopefully before the next release of FreeCAD. - John >> On Mar 9, 2019, at 11:25 PM, Efraim Flashner wrote: >> >> On Sun, Mar 10, 2019 at 02:14:15AM +, John Soo wrote: >> Hi guix, >> >> Just a quick update. I have little to report on freecad. I am still stuck >> packaging pyside2. I have looked over the debian packaging rules but I am >> unfamiliar with their packaging process. I did some research and it looks >> as though they are using the normal pybuild process with some alterations >> to some paths afterward. The package completely fails to compile for me >> and I am no expert on python build tooling. Here's what I have tried so far >> and the error: https://paste.debian.net/1072533. Any help would be very >> appreciated. >> >> Thanks, >> >> John >> On Fri, Feb 15, 2019 at 6:33 PM John Soo wrote: >>> >>> Thanks so much Paul! This is really helpful! >>> > On Feb 15, 2019, at 9:20 AM, Paul Garlick < pgarl...@tourbillion-technology.com> wrote: Hi John, > I have been getting a little stuck building the pyside2 dependencies There has been an effort to package pyside2 for Debian. This has been completed in the last six months. A good place to look for information is https://tracker.debian.org/pkg/pyside2 You can browse the source code and follow the links to the 'debian' directory, which contains the files that govern the packaging process. In general for Debian packages, the 'rules' file is worth reading and the 'patches' directory has the changes to the upstream code. One element that could be important in Guix is an update of patchelf to a recent commit (see 'update-patchelf.patch' in the patches directory). Best regards, Paul. > > I haven't tried building it myself yet, but two things come to mind: > Try using qtbase instead of qt, it has a much smaller footprint and will > likely be requested when it's time to include the package in Guix. > > You're using version 5.12.1, and in Guix we have qt 5.11.3. It's likely > the errors you're getting are because the version of Qt is different. > > -- > Efraim Flashner אפרים פלשנר > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > Confidentiality cannot be guaranteed on emails sent or received unencrypted
Re: Digimend kernel drivers for Guix
Tobias Geerinckx-Rice wrote: However, in this case, please use the even simpler: (arguments '(#:tests?)); no test suite Not sure what went wrong here, but this should obviously be: (arguments '(#:tests?)); no test suite Kind regards, T G-R signature.asc Description: PGP signature
Re: Crosscompiling C++ for powerpc64le fails
Hi Tobias, On Tue, 28 May 2019 18:07:02 +0200 Tobias Platen wrote: > Im trying to cross compile basic GNU software such as bash and coreutils > for powerpc. > > When building mpfr the build fails using the message above. I guess I > have to specify the include paths for glibc to the configure script, > since headers won't be found in /usr/include We have a special Guix-specific patch for gcc which makes it heed these environment variables: * CROSS_C_INCLUDE_PATH * CROSS_CPLUS_INCLUDE_PATH * CROSS_LIBRARY_PATH Try printing and/or setting those. gnu/packages/cross-base.scm already contains a SEARCH-PATHS form in CROSS-GCC which sets up the environment variables CROSS_LIBRARY_PATH, CROSS_C_INCLUDE_PATH, CROSS_CPLUS_INCLUDE_PATH, CROSS_OBJC_INCLUDE_PATH, CROSS_OBJCPLUS_INCLUDE_PATH, so it should have worked--but didn't. That still leaves the libc. Not sure how it gets included in the environment variables above. See gnu/packages/admin.scm's sunxi-tools for a horrible workaround that makes it work fine. We should probably fix this problem. pgp8yCOaLmZ5D.pgp Description: OpenPGP digital signature
Re: Digimend kernel drivers for Guix
Marlin, Marlin wrote: I have just managed to get the digimend kernel drivers packaged for guix: Cool! I encourage you to read the ‘Contributing’ section of the manual, set up your own git repository, and submit a patch adding this package to linux.scm. I don't mind merging this version eventually, but you'll have to do so sooner or later if you want to keep contributing (and I hope you will). Might as well jump in. (define-public digimend-kernel-drivers I realise this is the upstream name. I'm not sure what to do here. We currently have 2 separately packaged Linux kernel modules: vhba-module (which was first) and acpi-call-linux-module (the latter added by me). I'd really like to see some semblance of consistency in naming these things and don't think ‘-module[s]’ (for Guile?), ‘-driver[s]’ (not all modules are drivers, but I agree it's subtle), or ‘-kernel-’ (which kernel?) cut it. (package (name "digimend-kernel-drivers") (version "9") (source (origin (method url-fetch) (uri (string-append "[…long URL is long…]" Please keep lines shorter than 80 characters. Often indenting can make the difference (SOURCE and ORIGIN here could be on two separate lines, for example) but that won't help you here. You're already calling STRING-APPEND, so you can simply split up the URL: (uri (string-append "https://github.com/DIGImend/digimend-kernel-drivers/; "releases/download/v9/digimend-kernel-drivers-" … …or however you prefer. Also note the hard-coded ‘9’ that needs replacing by VERSION. (build-system linux-module-build-system) All lines from here on are misleadingly indented: this opening bracket should be even with that of SOURCE above. If you use emacs, fixing this is as easy as running C-M-q at the beginning of the package definition. If you don't (nobody's perfect), we provide a stand-alone (emacs) script to do this: ./etc/indent-code.el gnu/packages/FILE.scm PACKAGE …although I've never used it. See the ‘Formatting Code’ section of the manual. (arguments '(#:phases (modify-phases %standard-phases (delete 'check This works (and once re-indented it won't even exceed 80 characters), but consider the more conventional and easy-to-skim (arguments '(#:phases (modify-phases %standard-phases (delete 'foo; no foo gizmo …including the helpful comment. However, in this case, please use the even simpler: (arguments '(#:tests?)); no test suite (synopsis "Kernel Drivers for non-wacom Digital Tablets") ‘Drivers’ & ‘Digital Tablets’ shouldn't be capitalised; ‘Wacom’ should. However, I think the project already offers a good synopsis on their home page: how about "Linux drivers for generic graphics tablets"? (description "Provides Drivers for Tablets from \ companies like huion and ugee.") Same here: nouns in English don't need to be capitalised, proper nouns such as ‘Huion’ do (even if they don't do so themselves!). Why single out these two manufacturers? The home page lists a lot more. This is also far to short to be a description: ideally, they should be around ~10 lines. Here too, the home page has some good stuff ready to use. The DIGImend project aims at improving Linux support for generic graphics tablets. Essentially, this means any USB-connected drawing tablet not produced by Wacom (and often more affordable). This package supports tablets designed and sold by Huion, KYE, UC-Logic and Waltop, rebranded and sold by Aiptek, Genius, Monoprice, Princeton, Trust, and many others. This way, people searching for ‘Aiptek’ will still find this package, and I took the liberty of ‘keyword-stuffing’ the word ‘drawing’ in there for good measure ;-) This is still pretty short. If there's more to be said, please add it! (license gpl2))) This seems to be accurate. You'll need to add a ‘license:’ when moving this to linux.scm. Thank you for packaging this, and I hope you'll submit a git-formatted patch to guix-patches@ soon. If you get stuck, don't hesitate to ask questions on guix-devel@ or #guix. Kind regards, T G-R (nckx) signature.asc Description: PGP signature
Re: Documentation videos are being uploaded!
Hi/Hallo/Hola/Bonsoir :) All the videos are ready now :) > Agreed! The result is really nice, and the workflow you came up with is > a nice piece of engineering, too. Thank you very much Ludo :) > > Where should we go from there? > > There are several tasks that could be started (translating, adding color > output), but we could also go ahead and publish them on the web site, > WDYT? Yes, I have not forgotten about the coloring task, but I also wanted to finish them ASAP. Another pending task is creating the subtitles. As regards Spanish translations, I don't remember very well the process -if it goes to the translation project or not - but I can volunteer if its necessary, using as much neutral Spanish as I can. >Also, how should we publish them: once per week, say, and then > have a dedicate section of the web site? What are your thoughts on > this? I haven't thought about it, maybe now that they are ready we could let the community give their feedback for the following days? What about uploading them to the final site? Do we have to speak to someone else? > > Kudos Laura & Paul! I am cc'ing Paul :) Regards! Laura
Re: #850644: RFP: Guix in Debian
Control: block 850644 by 902174 Status update: technically working package! Needs more work within Debian to actually include it... On 2019-05-16, Vagrant Cascadian wrote: > On 2018-05-16, Vagrant Cascadian wrote: >> The main build/runtime dependencies missing from Debian appear to be >> guile-git, and possibly a recommends on guile-ssh: >> >> https://www.gnu.org/software/guix/manual/html_node/Building-from-Git.html >> https://www.gnu.org/software/guix/manual/html_node/Requirements.html > > Apparently, guix has grown a few additional dependencies since then... > > So in a bit of a focused run of packaging, I've been chasing the > dependency chain necessary to get guix building on Debian: > > * guile-gnutls needs to be (re)enabled in libgnutls*: > > https://salsa.debian.org/vagrant/gnutls Proposed a patch to re-enable: https://bugs.debian.org/905272#29 > * guile-json needs to be updated to version 1.2.0 (3.x is incompatible), > and I've pushed wip branches updating packaging for new upstream > versions: > > https://salsa.debian.org/debian/guile-json Updated to 1.2.0 in Debian experimental. A little awkward not updating to the newest upstream version, but hopefully that won't last forever... > * I've gotten some packaging for guile-git, guile-gcrypt, guile-ssh and > guile-sqlite3 which need some more polish and then uploading to > Debian: > > https://salsa.debian.org/vagrant/guile-gcrypt > https://salsa.debian.org/vagrant/guile-sqlite3 Uploaded and waiting in NEW for review: https://ftp-master.debian.org/new/guile-gcrypt_0.1.0-1.html https://ftp-master.debian.org/new/guile-sqlite3_0.1.0-1.html > https://salsa.debian.org/vagrant/guile-git Waiting for guile-bytestructures to get through NEW. > https://salsa.debian.org/vagrant/guile-ssh This is WIP, packaging needs some policy compliance issues addressed. > * guile-git required scheme-bytestructures, which I've packaged, and > needs to be uploaded before guile-git can be: > > https://salsa.debian.org/vagrant/scheme-bytestructures Uploaded and waiting in NEW for review: https://ftp-master.debian.org/new/scheme-bytestructures_1.0.5-1.html > After all that, I did get to the point where I could at least try to > compile guix: > > https://salsa.debian.org/vagrant/guix With local builds of the above packages, I've got a working guix package! It still needs a way to get the bootstrap binaries (bash, mkdir, tar and xz) from Guix; right now they're binaries shipped in the source! Ludovic Courtès worked on a patch that would in theory download those at run-time, but that is not yet working... I tried with using symlinks to the host's bash, mkdir tar and xz, but that resulted in the symlink getting copied into the store, which meant that the package build environment only ended up included a dead symlink and failed to build. Additionally, not using the exact same bootstrap binaries means that Guix's substitute servers would produce different results for all packages, and so substitutes wouldn't be able to be very useful. Bootstrapping the system with MES is also WIP in Guix, and it might be possible to build identical bootstrap binaries using MES in Debian at some point: https://bugs.debian.org/902174 The guix packaging for Debian also has a small number of test failures, at least one of which simply needs to be disabled because it accesses the network (which violates Debian policy). Also needs some updates to the packaging to get the guix-daemon running out of the box, for which there's a provided systemd service, and adding some guixbuild users, which shouldn't be too hard. So, still a lot to be done, but considerable progress! live well, vagrant signature.asc Description: PGP signature
Re: Installer: GUIX_IMAGE as /dev/sda on some hardware?
[De-CC'ing help-guix again.] Ludo'! Ludovic Courtès wrote: Ideally, we’d use an actual UUID object (or a string?) here rather than this Linux/udev-specific idiom. […] I believe using Guile-Parted we could map it back to a /dev name. Yah, 's one of the reasons that I haven't sent anything yet (the main one being shame, of course; car/cdr for the win & all that). Would that work? I'd looked in Guile-parted before but came up dry. To be fair I did little more than grep around for ‘uid’ and friends. So you tell me ;-) … Hum, wait a minute. Isn't that irrelevant? Doesn't Guix itself do exactly this when mounting file systems? Sigh, silly me, I should be able to re-use that… >_< Kind regards, T G-R signature.asc Description: PGP signature
Crosscompiling C++ for powerpc64le fails
Hello,
Im trying to cross compile basic GNU software such as bash and coreutils
for powerpc.
When building mpfr the build fails using the message above. I guess I
have to specify the include paths for glibc to the configure script,
since headers won't be found in /usr/include
Tobias
configure:10515: checking C++ compiler powerpc64le-linux-g++ -m64 -O3
Test compile:
configure:10529: powerpc64le-linux-g++ -m64 -O3 conftest.cc >&5
configure:10532: $? = 0
Test compile: namespace
configure:10569: powerpc64le-linux-g++ -m64 -O3 conftest.cc >&5
configure:10572: $? = 0
Test compile: std iostream
configure:10615: powerpc64le-linux-g++ -m64 -O3 conftest.cc >&5
In file included from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/ext/string_conversions.h:41:0,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/bits/basic_string.h:6361,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/string:52,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/bits/locale_classes.h:40,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/bits/ios_base.h:41,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/ios:42,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/ostream:38,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/iostream:39,
from conftest.cc:3:
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/cstdlib:75:15:
fatal error: stdlib.h: No such file or directory
#include_next
^~
compilation terminated.
configure:10618: $? = 1
failed program was:
/* This test rejects g++ 2.7.2 which doesn't have , only a
pre-standard iostream.h. */
#include
/* This test rejects OSF 5.1 Compaq C++ in its default pre-standard iostream
mode, since that mode puts cout in the global namespace, not "std". */
void someoutput (void) { std::cout << 123; }
int main (void) { return 0; }
configure:10644: result: no, std iostream
configure:10515: checking C++ compiler powerpc64le-linux-g++ -g -O2
Test compile:
configure:10529: powerpc64le-linux-g++ -g -O2 conftest.cc >&5
configure:10532: $? = 0
Test compile: namespace
configure:10569: powerpc64le-linux-g++ -g -O2 conftest.cc >&5
configure:10572: $? = 0
Test compile: std iostream
configure:10615: powerpc64le-linux-g++ -g -O2 conftest.cc >&5
In file included from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/ext/string_conversions.h:41:0,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/bits/basic_string.h:6361,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/string:52,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/bits/locale_classes.h:40,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/bits/ios_base.h:41,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/ios:42,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/ostream:38,
from
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/iostream:39,
from conftest.cc:3:
/gnu/store/l2gp3b9qfz2bwp0wcg7qz1xdgky8mfxr-gcc-cross-powerpc64le-linux-7.4.0/include/c++/cstdlib:75:15:
fatal error: stdlib.h: No such file or directory
#include_next
^~
compilation terminated.
configure:10618: $? = 1
failed program was:
/* This test rejects g++ 2.7.2 which doesn't have , only a
pre-standard iostream.h. */
#include
/* This test rejects OSF 5.1 Compaq C++ in its default pre-standard iostream
mode, since that mode puts cout in the global namespace, not "std". */
void someoutput (void) { std::cout << 123; }
int main (void) { return 0; }
configure:10644: result: no, std iostream
configure:10660: error: C++ compiler not available, see config.log for details
Re: Is qtwebkit building? Any substitute?
Thanks for the heads up. Note that I've also failed to build it locally multiple times, while it has worked some other times. I did not investigate further, sorry. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Is qtwebkit building? Any substitute?
Hi, Pierre Neidhardt skribis: > A friendly ping to know if someone has any update on why the > qtwebkit substitute is not available. > Still taking hours to compile :p It failed to build with ENOSPC several times, which we should fix: https://ci.guix.gnu.org/log/a7xbyhf0c33n15xmypzabcqny5xck2fq-qtwebkit-5.212.0-alpha2 I’ve started a new build for /gnu/store/fd787rgjys6h4kjg8m6ciwvkfxvshxvm-qtwebkit-5.212.0-alpha2.drv (x86_64-linux), let’s see how it goes. Ludo’.
Re: Installer: GUIX_IMAGE as /dev/sda on some hardware?
Hello! Giovanni Biscuolo skribis: > But wait! There's the /dev/disk/by-id/ tree, I did not notice it until > now! :-) > > That's the solution: > > > (bootloader > (bootloader-configuration > (bootloader grub-bootloader) > (target "/dev/disk/by-id/scsi-3600508b1001c75a3bebb04b23d19e249") > (keyboard-layout keyboard-layout))) > > I did not test this but it smells like running, if Guix devels agree I > think Installer should adopt /dev/disk/by-id by default, sorry I'm not > able to propose a patch for this Ideally, we’d use an actual UUID object (or a string?) here rather than this Linux/udev-specific idiom. So it would look like: (bootloader-configuration ;; … (target (uuid …))) Would that work? I believe using Guile-Parted we could map it back to a /dev name. WDYT? Ludo’.
Re: Let's merge staging!
Hi! Marius Bakke skribis: > The staging branch has been accumulating updates for a while now. > We have Mesa 19, Sphinx 2.0, GStreamer 1.16, ALSA 1.1.9, as well as some > Python updates. See `git shortlog -n master..staging` for the scoop. > > I suggest we "freeze" (meaning no further updates, only bugfixes) this > branch tomorrow at midnight UTC, and then merge it once the CI lights > are green. > > Anything missing before the freeze? Not from me, go for it! You can monitor: guix weather -c10 or similar for that branch. Thank you, Ludo’.
Re: url-fetch with referer
Hi, Pierre Neidhardt skribis: > For instance > > wget https://foo/bar.zip > > fails, while > > wget --referer https://foo https://foo/bar.zip > > works. I say that it’s a buggy web site. :-) More generally, we’ve added a couple of HTTP headers for issues that were relatively common. We could easily fix this one, but maybe you could first talk to the webmasters, because requiring ‘Referer’ sounds obnoxious; WDYT? (Note that in the meantime you can always work around the problem by writing your own fixed-output derivation.) Thanks, Ludo’.
Re: Documentation videos are being uploaded!
Hello! Ricardo Wurmus skribis: > Timothy Sample writes: > >>> As regards Paul's voice, I believe it depends on each person. For me >>> it is a little slow but also very clear and kind of calm. And I guess >>> the timing is based on the recordings that I did with my voice, so >>> sorry for that :/ >> >> I should be clear that I think Paul did a fantastic job. (Thanks Paul!) >> The pace in general is quite nice. Like you say, it is very calm and >> easy to follow. It was only the URL part that felt a little slow. > > I agree with everything you wrote, Tim. Laura and Paul have done an > excellent job. Agreed! The result is really nice, and the workflow you came up with is a nice piece of engineering, too. Where should we go from there? There are several tasks that could be started (translating, adding color output), but we could also go ahead and publish them on the web site, WDYT? Also, how should we publish them: once per week, say, and then have a dedicate section of the web site? What are your thoughts on this? Kudos Laura & Paul! Ludo’.
Digimend kernel drivers for Guix
I have just managed to get the digimend kernel drivers packaged for guix: https://framagit.org/marlin1113/guix-digimend-drivers This allowed me to work with my huion graphics tablet using the guix system. It's my first trial at packaging too, so i'll have to get some better documentation on the repo. Consider merging this package -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Can the builder access channel code?
Hello,
Pierre Neidhardt skribis:
> I'm working on a new build-systems from a channel.
> When building a package using this build-system, I get
>
> building
> /gnu/store/j1qracwgv7qbxslbf6755z8wcwlv3bcf-foobar-qux-hires-2010.drv...
> Backtrace:
>4 (primitive-load "/gnu/store/v4yp12m19g3bnn901kxa65xpifp?")
> In ice-9/eval.scm:
>191:35 3 (_ #f)
>213:21 2 (_ #f)
>223:20 1 (proc #)
> In unknown file:
>0 (%resolve-variable (7 . foobar-build) #)
>
> ERROR: In procedure %resolve-variable:
> Unbound variable: foobar-build
> builder for
> `/gnu/store/j1qracwgv7qbxslbf6755z8wcwlv3bcf-foobar-qux-hires-2010.drv'
> failed with exit code 1
> build of
> /gnu/store/j1qracwgv7qbxslbf6755z8wcwlv3bcf-foobar-qux-hires-2010.drv failed
> View build log at
> '/var/log/guix/drvs/j1/qracwgv7qbxslbf6755z8wcwlv3bcf-foobar-qux-hires-2010.drv.bz2'.
> guix build: error: build of
> `/gnu/store/j1qracwgv7qbxslbf6755z8wcwlv3bcf-foobar-qux-hires-2010.drv' failed
>
>
> Here is the offending part:
>
> (define* (foobar-build store name inputs
> #:key
> (tests? #f)
> (build-targets #f)
> (phases '(@ (my-guix build foobar-build-system)
> %standard-phases))
> (outputs '("out"))
> (search-paths '())
> (system (%current-system))
> (guile #f)
> (substitutable? #t)
> (imported-modules %foobar-build-system-modules)
> (modules '((my-guix build foobar-build-system)
>(guix build utils
>...
>
> The default value of the key argument "modules" is the problem. Is it
> possible that the builder cannot find channel modules, or any module out
> of the Guix tree?
So your derivation tries to use ‘foobar-build’ on the build side? That
sounds weird.
In general, build systems only import (guix build …) modules on the
build side; things like (guix build-system …) modules (not to be
confused!) are meant to be used on the host side.
HTH,
Ludo’.
Guile Days in Strasbourg, France, June 21–22
Hello Guilers & Guix! As a reminder, there will be two Guile Days in Strasbourg, France, on June 21st and 22nd: https://gnu.org/s/guile/news/join-guile-guix-days-strasbourg-2019.html If you’re already a Guile or Guix user or developer, please consider submitting a talk or a hands-on session on the Web site by June 8th: https://journeesperl.fr/jp2019/newtalk If you’d like to learn about Guile or Guix, we’d love to meet you there! You can email Julien Lepiller (Cc’d) or myself for any questions. Ludo’. signature.asc Description: PGP signature
