<jmd>rekado: I'm not familiar the the terminology. 802.1x is a normal wifi protocol?
<quigonjinn>I'm trying to build gcc for arm bare metal. The build process stops with an error, and after investigating with --keep-failed in /tmp , this error stops the build process: http://paste.lisp.org/display/325933 . I have set the environment-variable that guix outputs.
<rekado>quigonjinn: yes. This can happen when the build process tries to write somewhere outside its own output directory.
<rekado>quigonjinn: in that case you’d have to check that the target directories are all correct.
<rekado>I just built a first working version of Extempore (a musical Scheme)
<quigonjinn>target directory is gcc-drv-1/build/gcc/build. -o build/denmddeps is a relative path anyway. Is there a chance this is not the same error why my build process fails? because I reproduce this in /tmp
<lfam>Hm, I'm testing Danny's ldc patch from guix-devel. I used --dry-run to see what would happen, and it appears that 5 different copies of the source code will be downloaded. 4 gzip, 1 xz. And two different version number styles.
<civodul>technically, #:parallel-build? #f replaces "-jN" with nothing, not with "-j1"
<lfam>Perhaps they won't all be downloaded, but they will at least be built
<quigonjinn>I'm trying to find the correct way to change only that variable, from an inherited package definition, but failing so far. I'm trying something like: http://paste.lisp.org/+6ZIA . There's probably some horrible mistake there :)
<quigonjinn>lfam: I'm trying that at the moment. I should note that if I pass --fallback, and then enter the build directory, in a guix environment for that package and run: "make distclean", and then "configure" with the flags my guix package imposes, and "make" with no flags, the package builds.
<lfam>1/662 Test #1: build-druntime-ldc-unittest ................. Passed 46.97 sec
<ng0>I/we want to deliver a range of live-system with pre-configured guix/nix and our applications..I excuse in advance (though it's some time until we get there) for users reporting in who have not read the details.
<lfam>ng0: A flood of users who have not read the manual is a "good problem" :)
<ng0>but it's a perl module.. some day someone might need it.
<janneke>likewise libpgxx could go into `databases.scm' -- but it seems obsolete
<dvc>Is anyone against moving module-init-tools and libnfsidmap from the kernel section to the end of the file? I think it disturbs the flow of reading the linux-libre packages. Does this have to be two separate commits even if they are adjacent to each other?
<janneke>sure, i'm quite open for suggestion, i also had doubts.
<efraim>grep define-public gnu/packages/*scm makes me want to tear python.scm into many many pieces
<lfam>janneke: The lazy choice (that is, what I would have done) would be to use (gnu packages perl)
<ng0>systems get attractive by having a variety of applications available. we should have some kind of drop policy then.. for me it would be serious security issues which are unlikely to get patched and no package depends on it
<efraim>for inclusion in ffmpeg a library is all thats needed, but it can be called on its own
<janneke>lfam: re ImageMagick: I haven't verified if it's (still) needed, or if it should or should not be updated...
<lfam>ImageMagick is up to date in our package tree, but I'm wondering about the software running on hydra.gnu.org, and if it's possible for someone to actually run ImageMagick code on hydra.gnu.org from the internet. A bit unsettling...
<lfam>I don't know Hydra very well yet, but I haven't noticed many pictures on the site
<janneke>i'm afraid hydra.gnu.org might not be all that up to date, should ask civodul
<lfam>Well, I'm building your Hydra patches now. I will look around once its built
<lfam>I don't archive patch emails until they have been dealt with
<bavier1>looked at the first patch just now; a lot going on there
<davexunit>yeah it's not a trivial patch series that's for sure
<ng0>is someone really impatient waiting for ghc 8? I could then publish the latest build log in addition to the branch which can be seen on my gitlab project. I'll figure the problem out eventually, but maybe someone encountered this before with the previous haskell generation and has *the idea* how to beat it?
<quigonjinn>What's the elegant way to export an anvironmental variable before a build phase in a package definition?