bug#21987: Version 0.9 Fails to Compile on Raspbian

On Wed, Nov 25, 2015 at 05:02:46PM +0100, Ludovic Courtès wrote: > Mark H Weaver skribis: > > We should allow arm8* as well, no? Actually armN* for N >= 7. > Right. I did that in 968ae90. We’ll revisit it when ARMv10 is out. Currently (commit

bug#21987: Version 0.9 Fails to Compile on Raspbian

On Mon, Nov 30, 2015 at 06:43:37PM +0100, Ludovic Courtès wrote: > Could you check the value of ‘host_cpu’ in config.log? The pattern use > in guix.m4 is supposed to allow ‘armv7l’. Yes, that is what surprises me also. An excerpt of config.log: guix_system='armv7l-linux'

bug#21784: Alternate xz-5.0.4.tar.gz URL

On Sun, Nov 01, 2015 at 11:20:59AM +0100, Ludovic Courtès wrote: > Cool. Could you rename it to ‘xz-5.0.4.tar.gz’? Done! Andreas

bug#21784: Alternate xz-5.0.4.tar.gz URL

On Sat, Oct 31, 2015 at 11:41:41AM +0100, Ludovic Courtès wrote: > Could you put a copy at multiprecision.org? That would be great. Is that it? The result of "guix build xz -S" copied over: http://www.multiprecision.org/guix/0d7xnp3nji2mi4cw4jmd3mzbpija9a5a-xz-5.0.4.tar.gz Andreas

bug#21784: Alternate xz-5.0.4.tar.gz URL

On Fri, Oct 30, 2015 at 06:06:26PM +0100, Ludovic Courtès wrote: > So we need another solution. Any suggestions? I would not mind hosting it on enge.fr, but this is of course less reliable than "real" hosting, since the machine is in my living room. Alternatively, I could host it with a

bug#21620: tests/mpz/reuse intermittently fails on armhf-linux-gnu

On Wed, Oct 07, 2015 at 10:32:43PM +0200, Ludovic Courtès wrote: > Do you think it’s a likely problem? Andreas, could you try again on > your Novena with 2 cores turned off? I have trouble believing the explanation of overheating. The gmp test suite is carried out sequentially (they are not yet

bug#21288: Qt's bundled libraries must not be used

Commit 7431ede removes the webkit module from qt-4. Andreas

bug#21516: lsh and nettle

Hello, I just tried to use lsh from the latest core-updates commit (hopefully) on armhf. The command $ lsh-authorize identity.pub results in: Can't find the sexp-conv program sexp-conv comes from nettle, which is not installed in my profile. Adding nettle to the profile solves the

bug#21142: Sshfs-fuse requires fuse

Hello, when trying to execute sshfs from the sshfs-fuse package, I obtain fuse: failed to exec fusermount: No such file or directory I think that fuse should be a propagated input of sshfs-fuse. Andreas

bug#21111: possibly bogus in binary tarball

On Wed, Jul 22, 2015 at 12:55:13PM +0100, Dave Love wrote: The timestamps in the guix-binary-0.8.3.x86_64-linux.tar.xz tarball are all at the epoch, so unpacking it spews messages like tar: ./var/guix: implausibly old time stamp 1970-01-01 01:00:00 I guess that's not intentional, but if

bug#20358: MariaDB failed to link 'libgcc_s.so' with our ld-wrapper.

Now the problem occurs in gcc itself: http://hydra.gnu.org/build/402695/nixlog/2/tail-reload validating RUNPATH of 23 binaries in /gnu/store/nj9ps51n0pfdnn0qxq6cb32z5xy2g641-gcc-4.9.2-lib/lib... /gnu/store/nj9ps51n0pfdnn0qxq6cb32z5xy2g641-gcc-4.9.2-lib/lib/libvtv.so: error: depends on

bug#20358: MariaDB failed to link 'libgcc_s.so' with our ld-wrapper.

On Wed, Apr 29, 2015 at 06:37:07PM +0200, Ludovic Courtès wrote: I see 宋文武 did some work on CMake in core-updates, so hopefully this particular issue is gone now? Yes, core-updates now builds satisfyingly on x86_64, and the other architec- tures are catching up. Andreas

bug#20358: MariaDB failed to link 'libgcc_s.so' with our ld-wrapper.

On Thu, Apr 23, 2015 at 09:08:10PM +0200, Ludovic Courtès wrote: Andreas: ditto for the Qt 5 issue? With commit d074e2f, cmake, a dependency of qt, fails one of its tests: 99% tests passed, 1 tests failed out of 373 The following tests FAILED: 72 - BundleUtilities (Failed) Andreas

bug#20358: MariaDB failed to link 'libgcc_s.so' with our ld-wrapper.

Trying to build qt, I just had the same problem; it fails with the following messages (building on only one core to actually see the error message): [629/10115] CC obj/src/3rdparty/chromium/net/third_party/nss/ssl/libssl.sslver.o FAILED: cd

bug#20188: [wishlist] avoid unnecessary calls to substitute-binary

An even worse example: $ guix package --roll-back substitute-binary: updating list of substitutes from 'http://hydra.gnu.org'... Andreas

bug#18926: cmake-build-system should set CMAKE_INSTALL_LIBDIR and CMAKE_PREFIX_PATH

Commit 0d6f936 fixes the issue with CMAKE_PREFIX_PATH. I am closing this bug; if a problem occurs with CMAKE_INSTALL_LIBDIR, we may reopen it. Andreas

bug#20081: patch-source-shebangs crashes on broken symlink

On Wed, Mar 11, 2015 at 04:02:11PM +0100, Tomáš Čech wrote: I'm trying to create package for taskwarrior. Source tarball contain symlinks to nonexisting file `task': I would argue that this is not a bug in guix, but in the tarball. You can remove the link with an additional phase before

bug#18926: cmake-build-system should set CMAKE_INSTALL_LIBDIR and CMAKE_PREFIX_PATH

The patch does not work. I thought this was due to it returning the .cmake files themselves and not the directory containing them. Here, for instance, it contains /gnu/store/h30r6z3fc67h8557kd63vjjdlfpc58wj-libqtxdg-1.1.0/share/cmake/qt5xdg/qt5xdg-config.cmake Inside the build directory, I

bug#18926: cmake-build-system should set CMAKE_INSTALL_LIBDIR and CMAKE_PREFIX_PATH

On Sun, Mar 01, 2015 at 03:35:51PM +0100, Ludovic Courtès wrote: That’s not currently possible using the search path mechanism (and I can’t imagine such weird semantics.) I think the semantics is relatively clear: Match file names with a regular expression and, if there is a match, add the

bug#19803: gstreamer-0.10 fails tests

On Sat, Feb 07, 2015 at 09:45:22PM -0500, Mark H Weaver wrote: In fact, this was my motivation for commit 710f3ce44, which removed our last remaining user of gstreamer-0.10.x. However, we might want to add some software in the future that still needs gstreamer-0.10.x. We could still add them

bug#19803: gstreamer-0.10 fails tests

On Sat, Feb 21, 2015 at 12:56:58AM +0100, Taylan Ulrich Bayırlı/Kammer wrote: FYI I've been working on Audacity and all its dependencies today, and got irritated by the gstreamer-0.10 package which apparently never had a successful build. Was about to send a bug report... :-) It has been

bug#19742: Close

Applied in commit b01f89675d03202851a00c38d4995424bbb1879f. Andreas

bug#19743: Close

Applied in commit da466f7ff63e34aca271e603090f25ba471f009e. Andreas

bug#19866: Zip sources

Currently, the 'unpack phase of gnu-build-system assumes that the source is a (potentially compressed) tar file. It would be nice to automatically recognise and handle zip files, be it only by extension. Andreas

bug#19832: Deleting unused links is too slow

Hello, I just compiled a test package and tried a guix gc -d /path/to/package/in/store After printing deleting `/gnu/store/642pwarg5hppzh1gwadd07w0g4w3rwpx-nss-certs-3.17.3' deleting `/gnu/store/trash' deleting unused links... which is instantaneous, I need to wait for 5 minutes with the disk

bug#19832: Deleting unused links is too slow

On Tue, Feb 10, 2015 at 11:24:51PM +0100, Ludovic Courtès wrote: If you haven’t GC’d in a long time, it’s also likely to take longer. Maybe that was the problem. I tried again later to gc one package, and it was almost instantaneous. Which means that there might not be a problem after all.

bug#19821: Openssl 1.0.2 and cmake

Currently, libwebsockets fails to build because its dependency openssl is not found by cmake any more since we switched to 1.0.2. There is a patch in the cmake git at

bug#19764: Downgrade reported as an ugprade

Now, pseudo-upgrades are reported as downgrades. Namely, when the version number of a package does not increase, but something changes with respect to its inputs. I would suggest to treat them as upgrades. Andreas

bug#17202: Imagemagick lacks stable source URLs

The problem seems to be solved; for instance at the mirror ftp://sunsite.icm.edu.pl/packages/ImageMagick/ all versions since 2012 seem to be available.

bug#19749: orpheus does not build on mips64

On Tue, Feb 03, 2015 at 01:04:38AM -0500, Mark H Weaver wrote: The config.guess problem can be easily worked around by passing --build=triplet to configure. I would suggest something similar to what I did in the gmp package to get it working on armhf: (arguments `(#:configure-flags

bug#19749: orpheus does not build on mips64

Hello, the orpheus package fails to build on mips64 with the following message: checking build system type... ./config.guess: unable to guess system type This script, last modified 2001-07-12, has failed to recognize the operating system you are using. It is advised that you download the most up

bug#19708: Bowtie fails to build

On Wed, Jan 28, 2015 at 03:11:06PM +0100, Ricardo Wurmus wrote: Whether or not a platform is 64-bit is determined with uname. Both these errors relate to using uname. Clearly, only x86_64 is supported. Citing from Makefile: BITS=32 ifeq (x86_64,$(shell uname -m)) BITS=64 endif # msys

bug#19686: Bad source checksum in netpbm

This is a tricky error. I still had the svn checkout of the previous version on my disk: /gnu/store/4a6ck86ap94m397vmycxy98bmhws7h6a-svn-checkout So the recipe worked for me, since the hash and the file name corresponded to the package recipe. However, instead of the new, I actually compiled

bug#18740: Fixed

Fixed in commit bc0b89b.

bug#18740: xf86-video-openchrome fails to build on all platforms

The problem occurred between 2014-09-01: http://hydra.gnu.org/build/84728 and 2014-09-23:3.16.3. http://hydra.gnu.org/build/97172 In between we updated linux-libre twice (to 3.16.3 and 3.16.3), and glibc to 2.20. Andreas

bug#18741: xf86-video-ati fails to build on all platforms

Switching from 6.14.4 to 6.14.6 solves the problem. I suggest to do so although we are leaving R7.7; keeping with the same minor version should be safe (I also tried the latest version 7.5.0, but it requires a newer mesa). Andreas

bug#18581: icecat fails to build on i686

On Tue, Sep 30, 2014 at 01:37:08PM -0400, Mark H Weaver wrote: More importantly, the version of IceCat we are using is almost a year old, with no security updates applied during that time. We should update to IceCat 31, which is currently available only from Trisquel, here: This is a

bug#18221: Source of mit-scheme

On Sat, Sep 27, 2014 at 03:42:54PM -0400, Mark H Weaver wrote: That commit adds a top-level procedure 'source-directory' that is specific to mit-scheme. If it's kept at the top-level, it should probably be renamed to something like 'mit-scheme-source-directory'. Also, it would be good to

bug#18262: perl-tk intermittent failures due to parallel build

On Wed, Aug 13, 2014 at 04:20:47PM -0400, m...@netris.org wrote: I tried to add #:parallel-build #f to the arguments, but that flag seems to be unsupported in the perl-build-system, even though it is almost identical to the gnu-build-system. I think the following (untested) patch adds support

bug#18322: make check fails

A make distclean followed by bootstrap etc. solved the problem. Andreas

bug#18221: Source of mit-scheme

Hello, mit-scheme fails to build on mips64el-linux, because specific source is not downloaded for this system. Furthermore, I wonder if in the corresponding lines (match (%current-system) (x86_64-linux x86-64) (i686-linux i386) (_ c)) one need not also check for the target system in

bug#18070: Hydra does not cope well with offline build machines

For instance here: http://hydra.gnu.org/build/79392 There are lines lsh: Connect failed, (errno = 0) guix offload: error: failed to register GC root for '/gnu/store/8nklnmzj317ahk6ynz7k5748lhma8cgn-GD_2_0_33.tar.xz.drv' on '#build-machine name: enge.fr port: system: mips64el-linux user:

bug#17201: xf86-input-evdev fails to build

This is a known bug; I think it never built, as it requires udev, which we do not have yet. Andreas

bug#17117: Not all downloaded files are printed

Hello, it may happen that guix downloads many more files than it shows on screen: $ guix build openconnect The following files will be downloaded: /gnu/store/dsclp7vqfq7xwhdc4narnsh32dvw6s89-openconnect-4.99 /gnu/store/8f15savrvf13z1z9hi5cb5l6akdx4gzr-zlib-1.2.7

bug#16791: w3m fails to do any SSL certificate checking

I wondered whether the problem lied in our openssl. It does not seem so. openssl verify cert.pem on my problematic certificate does print as expected: error 18 at 0 depth lookup:self signed certificate error 10 at 0 depth lookup:certificate has expired Andreas

bug#16534: gstreamer-1.0.10 tests fail

On Fri, Jan 24, 2014 at 10:35:58PM +0100, Ludovic Courtès wrote: The last good commit was 40fed2d according to Hydra, and then it’s not clear when it broke because Hydra wasn’t healthy, but the GLib update is a suspect. I tried updating to glib-2.39.3. But the patches do not apply any more,

bug#16534: gstreamer-1.0.10 tests fail

On Fri, Jan 24, 2014 at 11:25:39AM +0100, Sree Harsha Totakura wrote: One testcase for gstreamer-1.0.10 fails on my computer. The following output is seen when this happens: I confirm that this happens now systematically on my machine also. According to hydra: Last successful build 2013-12-30

bug#14884: TLS connection not terminated properly

On Tue, Jan 21, 2014 at 05:56:05PM +0100, Ludovic Courtès wrote: I guess we’ll have to add that patch to Guile in ‘core-updates’, so we can actually benefit from it when building source derivations. Are the sources not fetched with the system guile in guix? So that we would first need to guix

bug#16484: Contradictory package count

Hello, installing a few packages, I get the following output: ... building profile '/nix/store/ylq6xn1599wfph4n6caw7kdd5wds4x9n-profile' with 65 packages.. 51 packages in profile The difference is, I think, that I consciously installed 51 packages, while the remaining 14 ones are pulled in

bug#15762: guix refresh -u broken

Hello, when executing guix refresh -u libextractor a new file is downloaded, the signature checked successfully, the statement gnu/packages/gnunet.scm:42:3: libextractor: updating from version 1.1 to version 1.2...is printed, but the file is not updated. Andreas

bug#15615: Pulseaudio build fails

On Wed, Oct 16, 2013 at 09:22:23PM -0400, David Thompson wrote: Have other Debian users worked around this issue? Well, you can delete the symbolic link, create a directory /dev/shm and mount a new tmpfs there: rm /dev/shm mkdir /dev/shm mount -t tmpfs -o size=1G tmpfs /dev/shm I did

bug#15564: Pulseaudio fails tests

On Tue, Oct 08, 2013 at 11:00:47PM +0200, Ludovic Courtès wrote: Quoth the manual (info (guix) Setting Up the Daemon): I think that’s an occurrence of this case, no? :-) Oh well, indeed; I remember being at the source of this comment... Sorry for the noise, this bug should be closed! Andreas

bug#15564: Pulseaudio fails tests

Hello, pulseaudio fails its tests on x86_64; the output of the build is attached. Here are the crucial lines: ... Running suite(s): Memblock shm_open() failed: Function not implemented 0%: Checks: 1, Failures: 1, Errors: 0 tests/memblock-test.c:86:F:memblock:memblock_test:0: Assertion 'pool_a !=

bug#15392: xorg-server FTBFS

On Mon, Sep 23, 2013 at 09:39:12PM +0200, Ludovic Courtès wrote: Could you try ‘strace -f’ so we see what goes on in the child? Thanks to joint work with Ludovic, the problem should be solved. Currently, hydra.gnu.org does not pick up the git repository, but at least, locally xorg-server

bug#15392: xorg-server FTBFS

On Sat, Sep 21, 2013 at 10:02:03PM +0200, Ludovic Courtès wrote: Looking at configure.ac, I think you have to do just that. Then you can check the value of XKB_BASE_DIRECTORY in config.log, to make sure everything’s right. I checked this already before, the attached header file looks good

bug#15392: xorg-server FTBFS

On Sun, Sep 22, 2013 at 11:01:12AM +0200, Andreas Enge wrote: When I become root outside the chroot, source the environment variables and run ./xtest, the tests succeed. Even more: Without being root, sourcing the environment variables and running make check inside the build directory also runs

bug#15392: xorg-server FTBFS

I tried the following patch, setting some xkb-related options for configuring xorg-server: diff --git a/gnu/packages/xorg.scm b/gnu/packages/xorg.scm index 9a0e3e2..096ad54 100644 --- a/gnu/packages/xorg.scm +++ b/gnu/packages/xorg.scm @@ -4279,10 +4279,23 @@ emulation to complete hardware

bug#15229: guix download does not understand https

The title says it all: guix download https://fedorahosted.org/releases/x/m/xmlto/xmlto-0.0.25.tar.bz2 results in ERROR: missing interface for module (gnutls) failed to download guix-file.Oty9Cl from https://fedorahosted.org/releases/x/m/xmlto/xmlto-0.0.25.tar.bz2; guix download: error:

bug#15153: Wrong hash for tzcode2013d

$ guix download http://www.iana.org/time- zones/repository/releases/tzcode2013d.tar.gz yields: /nix/store/4iavpv6axr15l1z35yyccfvn0l1vx7ba-tzcode2013d.tar.gz 1dh7nzmfxs8fps4bzcd2lz5fz24zxy2123a99avxsk34jh6bk7id But the hash in base.scm is 13xd30ngwhqmj7w216ghd5knvg047hzpc0xca5l297g5cwb62hza .

bug#14851: linux-libre-3.3.8-gnu disappeared

Am Freitag, 19. Juli 2013 schrieb Alexandre Oliva: However, considering we put out multiple GBs of builds per week, I don't think it's realistic to keep them all forever. Not in our own server, not at ftp.gnu.org. As far as I know, ftp.gnu.org would only be concerned with the source, that

bug#14890: Wrong hash for tzdata

$ guix build tzdata --no-substitutes -S ... starting download of `/nix/store/gryg2h8lp3s8cc4zgxw14yn7d0wgc9lq- tzdata2013d.tar.gz' from `http://www.iana.org/time- zones/repository/releases/tzdata2013d.tar.gz'... http://www.iana.org/.../tzdata2013d.tar.gz 100.0% of 213.8 KiB output path

bug#14851: linux-libre-3.3.8-gnu disappeared

The build of linux-libre-headers-3.3.8 currently fails because the tarball cannot be downloaded any more from http://linux-libre.fsfla.org/pub/linux-libre/releases/3.3.8-gnu/ Instead, there is a new version in http://linux-libre.fsfla.org/pub/linux-libre/releases/3.3.8-gnu1/ Should we

Re: Pango

. Andreas ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2013 Andreas Enge andr...@enge.fr ;;; ;;; This file is part of GNU Guix. ;;; ;;; GNU Guix is free software; you can redistribute it and/or modify it ;;; under the terms of the GNU General Public License as published

Re: Pango

The include files for pango reside in include/pango-1.0/pango/ Then the main include file include/pango-1.0/pango/pango.h includes lines like #include pango/pango-attributes.h without the pango-1.0. I see three solutions: One can modify the CPATH to include pango-1.0; I do not know how

Re: Pango

As an addendum, the same problem occurs for gdk-pixbuf with an additional directory named gdk-pixbuf-2.0. And there is a cross-package problem: Inside the pango package, the file pangocairo.h contains #include cairo.h So either we must replace this by cairo/cairo.h in the install phase of

Re: pkg-config disappeared

Am Samstag, 15. Juni 2013 schrieb Ludovic Courtès: It /is/ visible under its normal name: the package name is different from the variable name. What matters for ‘guix package’ is the ‘name’ field, not the name of the variable. Okay, I see. Since they are usually the same, I tend to forget...

Re: Demain

Am Freitag, 14. Juni 2013 schrieb Cyril Roelandt: Do you see the same test failures when trying to compile cairo by hand outside of Guix ? By hand I did not manage to compile due to my unpleasant mixture of debian and guix libraries. Then this is probably not an issue. Can you link sample

Re: Demain

Am Donnerstag, 13. Juni 2013 schrieb Andreas Enge: Seras-tu dans ton bureau? Je m'énerve sur cairo... Sorry, wrongly addressed personal mail to Ludovic! But maybe one of you knows the answer to my problem: I created a recipe for cairo, and lots of tests fail. Now I wonder

Re: What’s next?

Am Donnerstag, 16. Mai 2013 schrieb Ludovic Courtès: However, I would add a less ambitious 0.3 milestone, first, ideally to be released before July. For 0.3, I would like to add actual cross-compilation support. If everything goes well, that would allow the MIPS/N64 port to be bootstrap (and

Re: Error in compiling fontutils.scm

Am Dienstag, 7. Mai 2013 schrieb Ludovic Courtès: I believe this is fixed by 6d267f0. There was a circular dependency between the ghostscript and xorg modules, introduced in commit e0eb886, and leading to this admittedly obscure backtrace. Excellent, thanks for your help! One suggestion:

Error in compiling fontutils.scm

Right now, the following error occurs when compiling fontconfig.scm: $ make gnu/packages/fontutils.go /bin/mkdir -p `dirname gnu/packages/fontutils.go` ; \ LC_ALL=C\ ./pre-inst-env

Tests requiring root

I am trying to package lvm2 as a prerequisite for cryptsetup. Most tests fail with: ## teardown.../dev/mapper/control: open failed: Permission denied Failure to communicate with kernel device-mapper driver. Command failed and mknod: '/tmp/nix-build-

Re: New “guix refresh” command

Am Montag, 29. April 2013 schrieb Ludovic Courtès: Commit e0fbbc8 should fix it. Can you confirm? So far, I just tried the binary substituter, and it works. Excellent, thanks for all your effort! Andreas

Re: Xpdf

Am Montag, 1. April 2013 schrieb Ludovic Courtès: Perhaps we could patch xpdfrc to point to GhostScript’s font directory? I just added the gs-fonts package in core-updates, and modified xpdfrc accordingly. Andreas

Re: Binary substituter

Am Donnerstag, 18. April 2013 schrieb Ludovic Courtès: Basically 90% of the packages from either branch. See http://hydra.gnu.org:3000/eval/692?full=1 for master, for instance. It definitely does not work for me. guix build attr in master builds

Re: Binary substituter

Am Donnerstag, 18. April 2013 schrieb Ludovic Courtès: And guess what: until commit ea0ee75 (right now), the substituter mechanism was actually disabled in the installed daemon. Now it should really be enabled. :-) PS: I am using the later commit 6858f9d13217b14eeeacede9c42a279468242891

Re: core-updates: 'make' warnings

Am Mittwoch, 17. April 2013 schrieb Andreas Enge: With Ludovic, we just noticed yesterday that we independently added intltool in two different files. I am going to unify this. Done in commit d6b8cb5c4a54c35b31304b2c96c7ab0082434d2a in core-updates. Andreas

libsigsegv does not compile in core-updates

Here is what is output: checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/tmp/nix-build- libsigsegv-2.10.drv-0/libsigsegv-2.10': configure: error: C compiler cannot create executables See `config.log' for more details phase `configure' failed after 1

Xpdf

In the xorg branch, I just added the package xpdf. As a caveat: When displaying a pdf file obtained with latex, fonts are shown with a very bad quality, and there are error messages such as: Config Error: No paper information available - using defaults Config Error: No display font for

Re: Update on x.org

Am Freitag, 29. März 2013 schrieb Ludovic Courtès: Nice! The branch could probably be merged in ‘core-updates’ now. WDYT? Let us wait until the end of the week, since I still have a few things to work on. After commenting out some packages (see the latest git logs), all remaining ones

Re: [PATCH] gnu: add dependencies to poppler.

Am Sonntag, 24. März 2013 schrieb Cyril Roelandt: Note that zlib is not enabled by default, even if it is found on the system, because it is not safe according to the poppler developers. Andreas, do you know why ? Maybe we should remove it from the dependencies. There is some discussion at

Re: Update on x.org

Am Freitag, 22. März 2013 schrieb Cyril Roelandt: I cannot build xorg-server, though. I'm getting this error: Yes, the xorg-server check fails, which makes it likely that the server will also not work. I do not see why. Help would be appreciated. I tried adding xbcomp and xkeyboard-config to

Re: [PATCH] gnu: add dependencies to poppler.

Am Donnerstag, 28. März 2013 schrieb Cyril Roelandt: OK. Do you mind if I push this patch to the xorg branch, then ? Please do. Andreas

Re: [PATCH 2/2] gnu: Add libopenjpeg.

Am Dienstag, 26. März 2013 schrieb Cyril Roelandt: gnu/packages/libopenjpeg.scm | 56 There is already a file libjpeg.scm. How about putting the packages in the same file, named jpeg.scm, for instance? Andreas

Re: Update on x.org

Am Freitag, 15. März 2013 schrieb Cyril Roelandt: This hangs, I attached the error log. It seems like the mirrors for libpthread-stubs-0.3 are broken. The xorg ftp mirrors are broken for packages developed in the xcb project, but the http mirrors used to work. I just replaced them by the

Re: libxml2-python

Am Donnerstag, 14. März 2013 schrieb Ludovic Courtès: Andreas Enge andr...@enge.fr skribis: I think it would be better to change it to glibc (which is what both of us thought naturally that it was already). I think this occurrence needs to be changed: ./gnu/packages/base.scm:1091: (libc

Re: A pleasant low-hanging fruit

Am Sonntag, 10. März 2013 schrieb Cyril Roelandt: This works well with GNU packages, but breaks other packages: Ah, I noticed the same thing with a new package; I thought it was a mistake in my recipe... Andreas

Update on x.org

Hello, the client part is working, I just added xeyes as a test application in the xorg branch. So now we should be able to package applications requiring X! Andreas

Re: libxml2-python

Am Freitag, 8. März 2013 schrieb Ludovic Courtès: Glibc is automatically added as an input, under the name “glibc” (see build-system/gnu.scm). So you can just do something like: (lambda* (#:key inputs #:allow-other-keys) (substitute* setup.py ((/usr/include)

Re: libxml2-python

Am Donnerstag, 7. März 2013 schrieb Cyril Roelandt: From setup.py: # those are examined to find # - libxml2/libxml/tree.h # - iconv.h # - libxslt/xsltconfig.h includes_dir = [ /usr/include, /usr/local/include, /opt/include, os.path.join(ROOT,'include'), HOME ]; You could patch

libxml2-python

xorg-server requires mesa, and mesa requires python and libxml2, more exactly libxml2-python. This is supposed to be set up the python way using python setup.py build install which already does not work manually: failed to find headers for libxml2: update includes_dir Supposedly, one needs

Re: PKG_CONFIG_PATH

Am Sonntag, 3. März 2013 schrieb Ludovic Courtès: Andreas Enge andr...@enge.fr skribis: This is because it is not contained in a subdirectory lib/pkgconfig, but in share/pkgconfig. Should we add share/pkgconfig to the lines Yes, it’s non-conventional, but it won’t hurt to add it. Done

Re: lsof

Am Sonntag, 3. März 2013 schrieb Ludovic Courtès: Andreas Enge andr...@enge.fr skribis: the lsof tarball contains the source in a two-stage process: After unpacking, one is left with lsof_4.87_src.tar, which needs to be unpacked as well. Weird. I have seen it before, the tarball contains

lsof

Hello, the lsof tarball contains the source in a two-stage process: After unpacking, one is left with lsof_4.87_src.tar, which needs to be unpacked as well. I tried the following: (arguments `(#:phases (alist-replace 'unpack (lambda* (#:key source name version

Perl checks

The check phase of perl is disabled in the distribution, but no comment is given. What was the reason? Is it still valid? Andreas

Re: Initial cross-compilation support

Am Mittwoch, 27. Februar 2013 schrieb Ludovic Courtès: Commit 827d289 of the ‘core-updates’ branch adds cross-base.scm, which builds a cross tool chain. So if you type ‘guix build gcc-cross-mips64el-linux-gnu’, you get a cross-compiler (+ libc, binutils) for that platform. The compiler is

PKG_CONFIG_PATH

Concerning x.org, I am making some progress: The files missing on ftp are actually available on the http servers, as found out through #xorg-devel. Now I am trying to compile a few packages and need to add some dependencies. The following happens for xlsatoms during the configure phase:

X.org licenses

I started adding license information to the 184 packages in the X11 distribution, and did not get very far... There is a list of several very similar licenses used, see http://www.xfree86.org/current/LICENSE5.html Number 5.11 is referred to as x11 in license.scm; is it okay to use x11 for

Re: X.org licenses

Worst of all so far: font-daewoo-misc has the following COPYING: Copyright (c) 1987, 1988 Daewoo Electronics Co.,Ltd. !!! Andreas

Re: X.org licenses

Here is what the description of xfonts-scalable in debian says: This package is missing three fonts from the X.Org source archives because the license terms on the fonts do not meet the Debian Free Software Guidelines; they are the Type1 fonts Adobe Utopia, IBM Courier, and Bigelow Holmes

<    1   2   3   4   5   >