Hi,
> There is still at least one new failure, borg. Are there more? If so, we
> should revert the changes until they are ready.
I think it depends on how much work fixing them is. If it were just five
minutes then I'd say leave it in master and fix the packages that failed.
Otherwise revert.
Hi,
On Mon, 28 Nov 2016 17:08:49 -0800
Maxim Cournoyer wrote:
> (inputs
> - `(("python-setuptools" ,python-setuptools)
…
> + `(("python-setuptools" ,python-setuptools)
setuptools is now part of each Python installation on Guix, even for
python2 and pip does not require any special
On Tue, Nov 29, 2016 at 04:12:00PM -0500, Leo Famulari wrote:
> There is still at least one new failure, borg.
Most of the test failures can be fixed by using the
(add-installed-pythonpath) procedure to ensure that the installed borg
can be found by the test suite.
But there are still 4 failures
Christopher Allan Webber writes:
> Onwards and upwards!
> - Chris
In theory we could also try to init GuixSD from within an Debian
image (server), couldn't we?
So we could also make a list of commonly offered virtual server
distribution choices and try to init GuixSD from within them and
see i
flex-2.6.2 introduces breaking changes, I expect a lot of packages
breaking (unless the kde frameworks packages aren't a representative
sample). I think we need to keep flex-2.6.1 for now and change all
broken packages to flex-2.6.1 until they update...
* gnu/packages/gl.scm (mesa): Update to 13.0.1.
[native-inputs]: Move 'mesa-wayland-egl-symbols-check-mips.patch' to ...
[source]: ... here.
[arguments]: Don't apply patch.
[inputs]: Remove eudev.
---
gnu/packages/gl.scm | 28 +---
1 file changed, 5 insertions(+), 23 deleti
Hartmut Goebel skribis:
> Am 29.11.2016 um 15:27 schrieb Ludovic Courtès:
>> Good. When you fix it (and other failures, if any), we can start a new
>> evaluation or merge directly in master (the sooner the better!).
>
> Done.
>
> I'm very glad the new python build system is now in master. Thanks
Hello Guix!
A new release is long overdue!
We’ve accumulated lots of bug fixes and new bu^W features already.
So what are the next steps? I think mainly we should be freezing
‘staging’ today (let’s see if there are packages to “ungraft”!) and
start building it in the hope of merging it next wee
ng0 skribis:
> Hartmut Goebel writes:
>
>> Am 29.11.2016 um 15:27 schrieb Ludovic Courtès:
>>> Good. When you fix it (and other failures, if any), we can start a new
>>> evaluation or merge directly in master (the sooner the better!).
>>
>> Done.
>>
>> I'm very glad the new python build system
John Darrington skribis:
> * gnu/services/base.scm (file-system-shepherd-service): Use mount-file-system
> instead of manually mounting the file system.
[...]
> +#$(if create?
> + #~(mkdir-p #$target)
> + #~#t)
#~#t is equiv
Hi Ludo!
> How does that sound?
Stupid question: Is staging the core-updates branch? I thought that
the core-updates branch was already frozen, merged into master and
ready for the next set of core updates? But it sounds good :)
David
John Darrington skribis:
> * doc/guix.texi (Kerberos Services)[Krb5 Service]: New subsubheading.
> * gnu/services/kerberos.scm (krb5-service-type): New variable.
Please mention the configuration.scm changes.
> +@subsubheading Krb5 Service
> +
> +The krb5 service provides the configuration for K
Mathieu Lirzin skribis:
> David Craven writes:
>
>> LGTM!
>
> Pushed in commit 365de1e7a5b37f9fd88cd964cc7d47f6f729d053, with an
> updated Cuirass commit.
Thank you!
I plan to give it a try on the new machine (bayfront) Real Soon.
Ludo’.
Ricardo Wurmus skribis:
> Ludovic Courtès writes:
>
>> Ricardo Wurmus skribis:
>>
>>> “gvfs” is useful for more than just GNOME. For a long time I tried to
>>> figure out why USB devices would not be mounted automatically in Xfce
>>> and I ran gvfsd and the gvfs-* device monitor daemons manual
Updated the patch with your suggestions, added you as a co-author and I
pushed it to core-updates.
Thank you,
Manolis
Ludovic Courtès writes:
> Hello Guix!
>
> A new release is long overdue!
>
> We’ve accumulated lots of bug fixes and new bu^W features already.
>
> So what are the next steps? I think mainly we should be freezing
> ‘staging’ today (let’s see if there are packages to “ungraft”!) and
> start build
Currently we lack an build system for Go.
I encounter more and more applications I'd like to use or try,
written in Go. I know a bit about how things are structured in
the go build system, but not enough to deliver something usable.
Maybe it's not obvious for everyone, so if anyone with some
knowl
On Wed, Nov 30, 2016 at 02:09:17PM +0100, Ludovic Court??s wrote:
John Darrington skribis:
> * doc/guix.texi (Kerberos Services)[Krb5 Service]: New subsubheading.
> * gnu/services/kerberos.scm (krb5-service-type): New variable.
Please mention the configuration.scm c
On Wed 30 Nov 2016 14:09, l...@gnu.org (Ludovic Courtès) writes:
>> (define (validate-configuration config fields)
>>(for-each (lambda (field)
>>(let ((val ((configuration-field-getter field) config)))
>> -(unless ((configuration-field-predicate field) val)
>>
Ludovic Courtès writes:
> ng0 skribis:
>
>> Hartmut Goebel writes:
>>
>>> Am 29.11.2016 um 15:27 schrieb Ludovic Courtès:
Good. When you fix it (and other failures, if any), we can start a new
evaluation or merge directly in master (the sooner the better!).
>>>
>>> Done.
>>>
>>> I'm
Am 30.11.2016 um 09:20 schrieb Danny Milosavljevic:
> I think it depends on how much work fixing them is. If it were just five
> minutes then I'd say leave it in master and fix the packages that failed.
>
> Otherwise revert.
I strongly against reverting this! We already have a backlog of several
* gnu/packages/web.scm (fcgiwrap): New variable.
---
gnu/packages/web.scm | 35 +++
1 file changed, 35 insertions(+)
diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm
index 455d16d..54ab06e 100644
--- a/gnu/packages/web.scm
+++ b/gnu/packages/web.scm
@@ -226
* gnu/packages/patches/fcgi-2.4.0-gcc44-fixes.patch: New file.
* gnu/packages/patches/fcgi-2.4.0-poll.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register patches.
* gnu/packages/web.scm (fcgi): New variable.
---
gnu/local.mk | 2 +
gnu/packages/patches
On Wed, Nov 30, 2016 at 02:28:46PM +0100, Marius Bakke wrote:
> Ludovic Courtès writes:
> > So what are the next steps? I think mainly we should be freezing
> > ‘staging’ today (let’s see if there are packages to “ungraft”!) and
> > start building it in the hope of merging it next week. If every
On Wed, Nov 30, 2016 at 04:02:52PM +0100, Hartmut Goebel wrote:
> Am 30.11.2016 um 09:20 schrieb Danny Milosavljevic:
> > I think it depends on how much work fixing them is. If it were just five
> > minutes then I'd say leave it in master and fix the packages that failed.
> >
> > Otherwise revert.
Hi Guix!
I’ve pushed a few improvements to ‘guix refresh’ so we have a clearer
view of package coverage.
A first one is to report the lack of an updater for packages specified
on the command line so one can tell the difference between “no updater”
and “up-to-date”:
--8<---cut here---
On Wed, Nov 30, 2016 at 11:59:43AM -0500, Leo Famulari wrote:
> This is the currently running evaluation (post-merge) compared with
> before the merge:
>
> https://hydra.gnu.org/eval/109381?compare=109380&full=1#tabs-now-fail
>
> Already there are several hundred new failures... I'm not sure what
Am 30.11.2016 um 17:59 schrieb Leo Famulari:
> Fair points, but the master branch is not where we put unfinished things
> to be fixed.
Fair point, but results on hydra seem to be quite unreliable. So I
though this is okay, since Ludo asked me to merge ASAP. maybe I
misunderstood the exact meaning.
On Wed, Nov 30, 2016 at 12:26:00PM -0500, Leo Famulari wrote:
> On Wed, Nov 30, 2016 at 11:59:43AM -0500, Leo Famulari wrote:
> > This is the currently running evaluation (post-merge) compared with
> > before the merge:
> >
> > https://hydra.gnu.org/eval/109381?compare=109380&full=1#tabs-now-fail
Leo Famulari writes:
> On Wed, Nov 30, 2016 at 02:28:46PM +0100, Marius Bakke wrote:
>> Ludovic Courtès writes:
>> > So what are the next steps? I think mainly we should be freezing
>> > ‘staging’ today (let’s see if there are packages to “ungraft”!) and
>> > start building it in the hope of me
* gnu/packages/linux.scm (btrfs-progs/static): New variable.
---
gnu/packages/linux.scm | 30 ++
1 file changed, 30 insertions(+)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index a4639bd..8b6cce4 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/
* gnu/system/linux-initrd.scm (linux-modules, helper-packages): Add
btrfs modules when a btrfs file-system is used.
* gnu/build/file-systems.scm (check-file-system-irrecoverable-error,
check-file-system-ext): New variables.
(check-file-system): Support non ext file systems gracefully.
---
gn
ng0 writes:
> Christopher Allan Webber writes:
>
>> Onwards and upwards!
>> - Chris
>
> In theory we could also try to init GuixSD from within an Debian
> image (server), couldn't we?
>
> So we could also make a list of commonly offered virtual server
> distribution choices and try to init GuixS
On Wed, Nov 30, 2016 at 06:30:22PM +0100, Hartmut Goebel wrote:
> Fair point, but results on hydra seem to be quite unreliable. So I
> though this is okay, since Ludo asked me to merge ASAP. maybe I
> misunderstood the exact meaning. And have been too impatient.
Yes, the Hydra interface can be con
On Wed, Nov 30, 2016 at 06:48:15PM +0100, Marius Bakke wrote:
> Leo Famulari writes:
> >> A quick grep for 'replacement' digs up these grafts:
> >>
> >> * cairo (1059 rebuilds)
> >> * curl (1356 rebuilds)
> >> * cyrus-sasl (1360 rebuilds)
> >> * dbus (1187 rebuilds)
> >> * guile@
On Wed, Nov 30, 2016 at 01:18:38PM +0100, David Craven wrote:
> flex-2.6.2 introduces breaking changes, I expect a lot of packages
> breaking (unless the kde frameworks packages aren't a representative
> sample). I think we need to keep flex-2.6.1 for now and change all
> broken packages to flex-2.
On Tue, Nov 29, 2016 at 11:52:07PM +, ng0 wrote:
> Hi,
>
> I wanted to ask wether you made any progress with my darcs
> package or if there's anything other people can help out with or
> test.
The only thing left is to make it use the TLS certificate store
correctly, right?
I seem to remembe
Hello,
This small patch fixes a build error I encountered when adding hplip to
my cups-configuration-extensions.
Thanks,
--
Andy
From 5f1394b445dea80a37bddc9a9aa49d3498c2a8d3 Mon Sep 17 00:00:00 2001
From: Andy Patterson
Date: Wed, 30 Nov 2016 16:00:13 -0500
Subject: [PATCH] services: cups: Fo
Leo Famulari writes:
> On Tue, Nov 29, 2016 at 11:52:07PM +, ng0 wrote:
>> Hi,
>>
>> I wanted to ask wether you made any progress with my darcs
>> package or if there's anything other people can help out with or
>> test.
>
> The only thing left is to make it use the TLS certificate store
> c
Mathieu Lirzin writes:
> Pushed in commit a7cf4eb6d99838606d8ecfa776f7e4920dfbb7f5 with bug fixed
> and requested changes.
>
> Thanks.
To begin to test the service, I tried this with this[0] system
config today and failed. I tried some variations, moving around
the let, checking for typos, let*
On Wed, Nov 30 2016, ng0 wrote
Is there anything obvious I have to change?
Your `let` body contains both the `(cuirass-service ...)` form as
well as the `%desktop-services` form. A `let` form will take the
value of the last form in its body, so the `(cuirass-service ...)`
value is being thro
Hi Hartmut,
On Mon, 28 Nov 2016 22:31:44 +0100
Hartmut Goebel wrote:
> I just need some C programming hint: uid_t is an unsigned int, so
> comparing with -1 raises a warning (which IMO is the same as en error).
The system call handler in the Linux kernel does this, among other things:
#define l
According to:
https://hydra.gnu.org/eval/109381?filter=icecat#tabs-removed
the jobs for icecat on armhf and mips64el were removed in evaluation
109381 (corresponding to commit 663d5b5), but were present in the
previous evaluation 109380 (commit cd65d60).
Can anyone tell me why this happened?
43 matches
Mail list logo
