Marius Bakke writes:
> Kei Kebreau writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit 13fbd174b5ffe5c2cc59e637f7859d357ab33d97
>> Author: Kei Kebreau
>> Date: Thu Nov 2 15:33:08 2017 -0400
>>
>> gnu: itstool: Update to 2.0.4.
>>
>> * gnu/pa
Gábor Boskovits transcribed 5.3K bytes:
> Yesteday we had a discussion about that on irc.
> Here it goes:
>
>
> [15:15:16] hello guix!
> [15:16:01] do we have a proposed way to build pyc files
> reproducibly?
> [15:16:50] I've read in the report, that we are not there yet, but
> is someone wor
Am 05.11.2017 um 20:04 schrieb Gábor Boskovits:
> [15:37:41]At this stage we might as well wait for this to land
> upstream: https://www.python.org/dev/peps/pep-0552/
Bad news: PEP 552 proposes a new file-format for .pyc file, so this
change can not be back-ported to Python 3.6 and older.
--
Reg
Yesteday we had a discussion about that on irc.
Here it goes:
[15:15:16] hello guix!
[15:16:01] do we have a proposed way to build pyc files
reproducibly?
[15:16:50] I've read in the report, that we are not there yet, but
is someone working on it?
[15:17:58] g_bor: This is the report you ment
Hello,
Ricardo Wurmus skribis:
> we have some Makefile rules that download some bootstrap binaries for
> us. Why is this necessary? Could we ship these bootstrap binaries
> instead?
These makefile rules were here mostly so that the tarball is not too big.
They are gone now in ‘core-updates’:
Hi,
Konrad Hinsen skribis:
>> By default, file systems are automatically mounted at boot time. To
>> avoid that, you must add:
>>
>> (mount? #f)
>
> That works well indeed. But I actually want that NFS filesystem mounted
> at boot time, ideally (not strictly required though).
>
> Of course, t
Hi!
Hartmut Goebel skribis:
> answering on a mail which Ricardo CCed to me and which did not make it
> to the list yet. Thus I full-quote.
>
> Am 04.11.2017 um 23:30 schrieb Ricardo Wurmus:
>> How about this:
>>
>> --8<---cut here---start->8---
>> #!/home/reka
Ludovic Courtès writes:
>> Usage: guix build gcc-dcc
>>
>> Building gcc-dcc tests the diverse double compilation property
>> of the gcc that Guix is using.
>>
>> * gnu/packages/bootstrappable.scm: New file.
>> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
>
> Awesome! Does it build fine out-of-the
Hi!
Eric Bavier skribis:
> I ran the gnulib lock tests with the be95b17ae commit and the tests passed,
> then with the commit directly before and they failed; so I'm fairly confident.
Great, thanks for testing.
> Attached is an updated patch, which remove the *-gnulib-multi-core patches
> an
Hello!
Ricardo Wurmus skribis:
> When building packages, Guix embeds the absolute file name of the output
> directory in the resulting binary. That’s usually fine and what we
> want.
>
> Now let’s assume that we’d like to build the GCC sources with diverse
> double compilation: we’d have a “gcc
Jan Nieuwenhuizen skribis:
> From c91609e847066c384826d726033146e08d8185ed Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen
> Date: Thu, 2 Nov 2017 06:52:46 +0100
> Subject: [PATCH] gnu: Add clang-gcc, gcc-ddc. WIP
>
> Usage: guix build gcc-dcc
>
> Building gcc-dcc tests the diverse double co
Heya,
Dave Love skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi,
>>
>> Hartmut Goebel skribis:
>
>>> I'm in favor of (automatically?) splitting of "development" packages,
>>> including the headers and the static libs (much like the "-devel" or
>>> "-dev" packages in other distribution
Dave Love skribis:
> Pjotr Prins writes:
>
>> But, really, I think when talking embedded systems and containers we
>> all want tiny. Even HPC can benefit. Tiny containers may be an
>> attractive proposition.
>
> Yes, containers aside, dependencies in Guix are one of the reasons I'm
> currently u
Hello,
Dave Love skribis:
> Efraim Flashner writes:
>
>> On Tue, Oct 31, 2017 at 02:00:35PM +0100, Vincent Legoll wrote:
>>> Hello,
>>>
>>> On Tue, Oct 31, 2017 at 1:35 PM, Dave Love wrote:
>>> > Why is linux-libre-headers a long way behind linux-libre (currently at
>>> > version 4.4.47, comp
Jan Nieuwenhuizen skribis:
> Ludovic Courtès writes:
>
>> Here’s an update on reproducibility in Guix:
>>
>>
>> https://www.gnu.org/software/guix/news/reproducible-builds-a-status-update.html
>
> At least 78% to possibly 91% reproduciblility of packages is not bad.
>
> Is there a (small) core
Hi!
Timothy Sample skribis:
> Andy Wingo writes:
>
>>> Do we really need a compile-time dependency (GDM in master doesn’t
>>> depend on gnome-shell, after all), or can we just have a hard-coded
>>> /run/current-system/bin/gnome-shell somewhere? Granted, that’s not very
>>> elegant, but it migh
Hi!
Chris Marusich skribis:
> l...@gnu.org (Ludovic Courtès) writes:
[...]
>> Or we mount the host store over 9p and exec a dynamically-linked Guile
>> from there.
>
> I understand hat by "9p" you mean to share the file system with the VM,
> but I don't quite understand what this option entail
Hi Guix,
we have some Makefile rules that download some bootstrap binaries for
us. Why is this necessary? Could we ship these bootstrap binaries
instead?
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
Hi Ludo,
> By default, file systems are automatically mounted at boot time. To
> avoid that, you must add:
>
> (mount? #f)
That works well indeed. But I actually want that NFS filesystem mounted
at boot time, ideally (not strictly required though).
Of course, the real problem is that I cannot
Hi,
Ricado proposed a new and better solution already. Nevertheless I want
to comment on this proposal, sint it includes a pitfall and would not work:
Am 03.11.2017 um 22:17 schrieb Ricardo Wurmus:
> exec /home/rekado/.guix-profile/bin/python
> <(/run/current-system/profile/bin/tail -n +4 "$0")
Hi,
answering on a mail which Ricardo CCed to me and which did not make it
to the list yet. Thus I full-quote.
Am 04.11.2017 um 23:30 schrieb Ricardo Wurmus:
> How about this:
>
> --8<---cut here---start->8---
> #!/home/rekado/.guix-profile/bin/guile --no-auto-
Christopher Baines writes:
> However, I think that the file wrapping approach has advantages for
> visibility. Maybe it could be tweaked to keep ensure the wrapper script
> has the same name as the script its wrapping, e.g. when wrapping foo,
> replace foo with a bash script, and move the real s
22 matches
Mail list logo
