Maxim Cournoyer writes:
H! Maxim
> Thank you Jan for sharing these precious notes!
At FOSDEM'17, Manolis [cc] inspired me with his talk to have a look at
HURD and help.
Sadly, the above recipe is all the help I found to offer until now, but hey.
> I've saved your message; I had started looking
Hello Rodger,
Rodger Fox writes:
> Thanks for the feedback on this. I think it was just my mistake.
> This is what I was looking at: GiB Mem : 16.6/2.929
> After using 'free', which gives more reasonable output, I think top is
> reporting a percentage. I never realized that, and it seems unintui
Ricardo Wurmus writes:
> Roel Janssen writes:
>
>> From de9f486828827b1d024cad4918eed3ed96202cc0 Mon Sep 17 00:00:00 2001
>> From: Roel Janssen
>> Date: Wed, 26 Apr 2017 10:30:52 +0200
>> Subject: [PATCH] import: Update Bioconductor release to 3.5.
>>
>> * guix/import/cran.scm: Change Bioconduc
I am pleased to announce the release of Mes 0.5, representing 249
commits over 4 months. Mes is now self-hosting, or rather it features
a mutual self-hosting Scheme interpreter and C compiler: mes.c and
mescc; a Nyacc-based C compiler backend that also works separately
with Guile.
* About
M
Leo Famulari writes:
> On Sat, Apr 22, 2017 at 12:27:11AM +0200, Ludovic Courtès wrote:
>> I’m going to be mostly away for a week, but it would be nice if we could
>> release after that, wouldn’t it?
>>
>> I think we’ll have to postpone work on the installer though since that
>> would leave too
Roel Janssen writes:
>> I’d be happy if you could take care of the mass update. I should note
>> that sometimes new inputs are required. To find them I usually run the
>> update in a separate branch where I’ve applied changes to import anew
>> and compare with the existing package expression w
Jan Nieuwenhuizen skribis:
> Ludovic Courtès writes:
>
>> Thoughts? Ideas?
>
> Great! With this patch applied to master I get
>
>
> Testsuite summary for GNU Guix 0.12.0
> ===
Ricardo Wurmus skribis:
> It’s a little unfortunate that packages are developed together with
> everything else, because this means that there is no way for people to
> opt out of breaking changes until the next release without also opting
> out of getting any updates at all.
It’s both a strengt
Hello!
Ricardo Wurmus skribis:
> Mekeor Melire writes:
[...]
>> And secondly, each user could have a user.scm e.g. like
>>
>> (user-configuration
>> ; ...
>> (aliases
>> '(
>> ("sysrec" "system reconfigure")
>> ("pl" "pull")
Hello!
Chris Marusich skribis:
> Chris Marusich writes:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
There appear to be (at least) two problem that prevent this naive
solution from working, which might point us in the right direction:
First, the GRUB menu is trying to find
Ricardo Wurmus skribis:
> Leo Famulari writes:
>
>> On Tue, Apr 25, 2017 at 02:33:13PM -0400, Leo Famulari wrote:
>>> I just merged master into staging and started a new evaluation. Barring
>>> any new complications, I plan to merge staging into master later today.
>>
>> I merged the staging bra
Hello,
Thomas Danckaert skribis:
> From: Chris Marusich
> Subject: Re: JARs and reference scanning
> Date: Tue, 25 Apr 2017 22:34:02 -0700
>
>>> I have to admit that I do not know at all how the reference
>>> scanning and
>>> dependency-tracking in the store works.
>>
>> As I understand it, the
Hi!
Andy Wingo skribis:
> On Sat 22 Apr 2017 15:19, l...@gnu.org (Ludovic Courtès) writes:
>
>> The closure of Guix built with 2.0 is 193.8 MiB; when built with 2.2,
>> it’s 311.8 MiB. Guix itself goes from 66 to 150 MiB:
>>
>> $ du -ms
>> /gnu/store/jh07pwbyf5dbpdd5q0nvgagqkgmh76nh-guix-0.12.
From: l...@gnu.org (Ludovic Courtès)
Subject: Re: store reference detection (was Re: JARs and reference
scanning)
Date: Thu, 27 Apr 2017 15:46:59 +0200
Really? Qt/WxWidgets “hide” store references by default?
Not by default. But there are cases were I've been bitten:
- Qt has a “QStringLi
Hi,
clouds are everywhere and this one wasn't mentioned here before so I have to
ask.
We need to teach our GuixSD how to fly among these systems.
The skill we need to learn this time is "OnApp".
Has anyone used it before? I'm totally unaware of most cloud solutions as
I'm not professionally invol
* doc/cuirass.texi (Introduction): Fix typo and use American English spelling.
---
doc/cuirass.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/cuirass.texi b/doc/cuirass.texi
index e5f29a6..ff5f7b0 100644
--- a/doc/cuirass.texi
+++ b/doc/cuirass.texi
@@ -70,7 +70,7
If I may make a suggestion, coming from a place of ignorance.
How about a stable branch that would be opt-in?
On Thu, 27 Apr 2017 15:29:53 +0200
l...@gnu.org (Ludovic Courtès) wrote:
> Ricardo Wurmus skribis:
>
> > It’s a little unfortunate that packages are developed together with
> > everyth
Hi Ricardo!
On April 27, 2017 8:28:25 AM PDT, Ricardo Wurmus wrote:
>* doc/cuirass.texi (Introduction): Fix typo and use American English
>spelling.
>---
> doc/cuirass.texi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/doc/cuirass.texi b/doc/cuirass.texi
>index e5f29a
>... -V gnu-disk-image /mnt/disk-image-partition-1.
> xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
That's because all characters in an ISO 9660 volume identification need to be
one of "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_".
If you use more complicated labels you
Am 27.04.2017 um 15:46 schrieb Ludovic Courtès:
> ‘propagated-inputs’ is one way to manually specify run-time references.
> It works at the package level and not at the store level—that is, the
> store item’s references are unaffected by what ‘propagated-inputs’
> contains. It’s usually enough for
Something like this (totally untested):
diff --git a/gnu/build/file-systems.scm b/gnu/build/file-systems.scm
index 0cb84b8aa..be512d59c 100644
--- a/gnu/build/file-systems.scm
+++ b/gnu/build/file-systems.scm
@@ -230,6 +230,55 @@ Trailing spaces are trimmed."
^L
;;;
+;;; ISO9660 file systems.
On Wed, 26 Apr 2017 20:09:33 +0200
Petter wrote:
> On Tue, 25 Apr 2017 22:36:27 -0500
> Eric Bavier wrote:
>
> > Could you ping the developer about porting some of these fixes to their
> > fork? I think we'd want to create a local patch for at least the first
> > commit. The others could wait
22 matches
Mail list logo
