l...@gnu.org (Ludovic Courtès) skribis:
> Tomáš Čech skribis:
>
>> On Wed, Mar 11, 2015 at 06:32:30PM +0100, Andreas Enge wrote:
>>>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 fi
On Sun, Apr 05, 2015 at 11:05:34PM +0200, Ludovic Courtès wrote:
Tomáš Čech skribis:
I'm afraid I can reproduce it.
It’s a different problem this time. :-)
--%%---
[...]
(packages
(append
(list
;; absolutely
l...@gnu.org (Ludovic Courtès) writes:
> Could you send the output of:
>
> $(guix build -e '(@ (gnu packages commencement) gcc-final)' | grep -ve
> -lib)/bin/gcc -dumpspecs
>
> It could be that the patching of config/gnu-user*.h ends up adding
> -rpath in the wrong place.
Here it is:
--8<
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver skribis:
>>
>>> readelf reveals that indeed, the ld.so used by localedef,
>>>
>>>
>>> /gnu/store/l2bkyclkm0lph48mfs6jbndj9p0y41g8-glibc-2.21/lib/ld-linux-armhf.so.3
>>>
>>> does have RUNPATH set: (excerpt of "
l...@gnu.org (Ludovic Courtès) skribis:
> Commit 36d2a3a disables this particular test, and Hydra successfully
> built GLib.
The above message should have closed the bug. Done now!
Ludo’.
Ricardo Wurmus skribis:
> Peter Baumgarten writes:
>
>> The OS was Fedora 21 x86_64, attached is the log
>
> This looks similar to this bug report:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19780
#19780 is now closed, so I’m closing this bug as well (the fix is
currently in the ‘core-update
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
> The other day I ran "guix package -d 1d" thinking it will preserve the
> current generation, but it didn't. If I'm not mistaken, there's no
> recovery from that either.
>
> Any command that will delete even the current generation
Fixed in 381ac93, thanks!
Ludo’.
宋文武 writes:
>> [...]
>>>
>>> The idea to generate profile from search-paths is not new,
>>> I heard it from you IIRC.
>>> I think it's the time to do it.
>>
>> Agreed, the plan makes sense and I think we have all the bits.
>>
>> A related question is whether to encode search path environment
>> v
