Why is IceCat now only 'supported' on Intel-systems?

[Mark H Weaver]

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?

I guess that the 'supported-systems' field of some package that 'icecat'
depends on was recently changed, but I was unable to find anything
obvious by grepping through the output of "git log -p".

Debian includes Firefox packages for 'armhf' and 'mips64el', so it's
obviously possible to get it working on those platforms.

I find it disturbing that we seem to be in the habit of removing
non-Intel systems from 'supported-systems' fields in packages that other
distros are able to get working on non-Intel.  These are bugs to be
fixed, not swept under the rug to get them out of sight.

  Mark

Re: Unable to configure a system with 'cuirass-service'

[Carlo Zancanaro]

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 thrown away.


Try removing one of the closing parentheses after `%desktop-services`
and add it after the `(cuirass-service ...)` form. (This has the effect
of moving `%desktop-services` out of the `let` body.)


signature.asc
Description: PGP signature

Unable to configure a system with 'cuirass-service'

[ng0]

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* instead of let, etc, but I
wasn't succesful.
What does this mean? I am able to configure the system with this,
but finally (cuirass-service) is silently ignored and never makes
it into the new system.

Is there anything obvious I have to change?

[0]:  https://ptpb.pw/lIwS.scm

Re: state of darcs

[ng0]

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
> correctly, right?
>
> I seem to remember that the WIP Darcs package fails to connect to TLS
> servers when it can't find the certificate store. Is that right? That's
> better than if it silently fails to validate the server's certificate.

Yes, that's correct. And as far as I can recall discussions, it
was because of some other application, curl maybe? I'm not sure.

The interaction with non-tls darcs servers worked.
-- 
♥Ⓐ  ng0  | ng0.chaosnet.org

[PATCH] services: cups: Follow symlinks when installing extensions.

[Andy Patterson]

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: Follow symlinks when installing extensions.

* gnu/services/cups.scm (union-directory): Use "stat" when calling
"find-files" to follow symlinks.
---
 gnu/services/cups.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/services/cups.scm b/gnu/services/cups.scm
index 391046a..df1843e 100644
--- a/gnu/services/cups.scm
+++ b/gnu/services/cups.scm
@@ -894,7 +894,7 @@ IPP specifications.")
 (if (file-exists? dst)
 (format (current-error-port) "warning: ~a exists\n" 
dst)
 (symlink src dst
-(find-files (string-append package path
+(find-files (string-append package path) #:stat stat)))
  (list #$@paths)))
   (list #$@packages))
  #t
-- 
2.10.2

Re: state of darcs

[Leo Famulari]

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 remember that the WIP Darcs package fails to connect to TLS
servers when it can't find the certificate store. Is that right? That's
better than if it silently fails to validate the server's certificate.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: flex: Update to 2.6.2.

[Leo Famulari]

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.6.1 until they update...

How about putting it on core-updates? I don't expect that we'll try
building that for at least 1 month, and I'd hate to forget about this
update.

Re: Preparing for 0.12.0

[Leo Famulari]

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@2.0  (1457 rebuilds)
> >> * libtiff(1672 rebuilds)
> >> * libxslt(2765 rebuilds)
> >> * pixman (1061 rebuilds)
> >> * ruby   (344 rebuilds)
> >> 
> >> There is probably a fair bit of overlap between cairo, dbus and pixman.
> >> Are these OK for staging? Ruby is an obvious candidate, I'll do that.
> >
> > I think it's okay to ungraft those packages on staging. Thanks Marius!
> 
> Done! I took the liberty of merging 'master' as well to get the recent
> cairo graft. Luckily no conflicts. Also updated dbus to the latest
> stable '1.10.14' (from 1.10.12).
> 
> Apparently ruby was already ungrafted.

Thank you!


signature.asc
Description: PGP signature

Re: New python build system merged

[Leo Famulari]

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 confusing, and the CI server itself can
fail in suprising or spurious ways, as you saw with xorg-server...

> Some errors I checked are like this one:
> 
> @ build-succeeded 
> /gnu/store/nzjcl8aviiz4643n13nn5vxfn540x1xb-xorg-server-1.18.4.drv -
> guix build: error: failed to create GC root 
> `/home/hydra/offload-20121227-hydra.gnu.org-8762': File exists
> /gnu/store/j2pj0lhwwd430y5vfc6whrr5p4fc2b5m-xorg-server-1.18.4

I think the vast majority of the "failed" packages are a result of this
failure. But, I got a substitute for that package from a master branch
HEAD today, so I think it's not a "real" failure. I asked Hydra to redo
that build.

> Or even like this one
> , which fail
> with no visible error:
> 
> @ build-succeeded /gnu/store/i4dl6i1rz6pvcqhh5g70vqhbpa0nkswj-swig-3.0.5.drv -
> /gnu/store/89rx3gby3b8f732alz3yrm0s78s0nnb8-swig-3.0.5

I noticed this on the python-build-system evaluation, and I restarted it
since it seemed like a spurious failure. I can get a substitute for it,
so I think it's okay, now.

> So hydra seems to have some problem, which makes it really hard to track
> down issues.

Yes, it's true. And since none of us are motivated to hack on it so far,
we'll probably put up with it until the new Hydra replacement server,
bayfront, is operational. The official ETA is "Real Soon" [0] ;)

http://lists.gnu.org/archive/html/guix-devel/2016-11/msg01253.html

Re: Hosting a GuixSD server on commodity hosting platforms, a journey

[Christopher Allan Webber]

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 GuixSD from within them and
> see if it just works.
> Is there anyone who tried that before?

That's what most of the NixOS guides do.

(Btw, was moving this from help-guix to guix-devel for a specific
reason?)

[PATCH 2/2] system: Add btrfs file system support.

[David Craven]

* 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.
---
 gnu/build/file-systems.scm  | 30 --
 gnu/system/linux-initrd.scm | 10 +++---
 2 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/gnu/build/file-systems.scm b/gnu/build/file-systems.scm
index 431b287..9f57ee5 100644
--- a/gnu/build/file-systems.scm
+++ b/gnu/build/file-systems.scm
@@ -410,12 +410,15 @@ the following:
 (else
  (error "unknown device title" title
 
-(define (check-file-system device type)
-  "Run a file system check of TYPE on DEVICE."
-  (define fsck
-(string-append "fsck." type))
-
-  (let ((status (system* fsck "-v" "-p" "-C" "0" device)))
+(define (check-file-system-irrecoverable-error prog code device)
+  (format (current-error-port)
+  "'~a' exited with code ~a on ~a; spawning Bourne-like REPL~%"
+  prog code device)
+  (start-repl %bournish-language))
+
+(define (check-file-system-ext device type)
+  (let* ((fsck (string-append "fsck." type))
+ (status (system* fsck "-v" "-p" "-C" "0" device)))
 (match (status:exit-val status)
   (0
#t)
@@ -428,10 +431,17 @@ the following:
(sleep 3)
(reboot))
   (code
-   (format (current-error-port) "'~a' exited with code ~a on ~a; \
-spawning Bourne-like REPL~%"
-   fsck code device)
-   (start-repl %bournish-language)
+   (check-file-system-irrecoverable-error fsck code device)
+
+(define (check-file-system device type)
+  "Run a file system check of TYPE on DEVICE."
+(cond
+ ((string-prefix? "ext" type)
+  (check-file-system-ext device type))
+ ((string-prefix? "btrfs" type)
+  (zero? (system* "btrfs" "device" "scan")))
+ (#t (format (current-error-port)
+ "Don't know how to check '~a' file systems; skipping~%" 
type
 
 (define (mount-flags->bit-mask flags)
   "Return the number suitable for the 'flags' argument of 'mount' that
diff --git a/gnu/system/linux-initrd.scm b/gnu/system/linux-initrd.scm
index 174239a..de8b785 100644
--- a/gnu/system/linux-initrd.scm
+++ b/gnu/system/linux-initrd.scm
@@ -193,6 +193,9 @@ loaded at boot time in the order in which they appear."
   ,@(if (find (file-system-type-predicate "9p") file-systems)
 virtio-9p-modules
 '())
+  ,@(if (find (file-system-type-predicate "btrfs") file-systems)
+'("btrfs")
+'())
   ,@(if volatile-root?
 '("fuse")
 '())
@@ -200,11 +203,12 @@ loaded at boot time in the order in which they appear."
 
   (define helper-packages
 ;; Packages to be copied on the initrd.
-`(,@(if (find (lambda (fs)
-(string-prefix? "ext" (file-system-type fs)))
-  file-systems)
+`(,@(if (find (file-system-type-predicate "ext4") file-systems)
 (list e2fsck/static)
 '())
+  ,@(if (find (file-system-type-predicate "btrfs") file-systems)
+(list btrfs-progs/static)
+'())
   ,@(if volatile-root?
 (list unionfs-fuse/static)
 '(
-- 
2.9.0

[PATCH 1/2] gnu: Add btrfs-progs/static.

[David Craven]

* 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/linux.scm
@@ -2714,6 +2714,36 @@ easy administration.")
 ;; GPL2: Everything else.
 (license (list license:gpl2 license:gpl2+
 
+(define-public btrfs-progs/static
+  (package
+(name "btrfs-progs-static")
+(version (package-version btrfs-progs))
+(build-system trivial-build-system)
+(source #f)
+(arguments
+ `(#:modules ((guix build utils))
+   #:builder
+   (begin
+ (use-modules (guix build utils)
+  (ice-9 ftw)
+  (srfi srfi-26))
+
+ (let* ((btrfs  (assoc-ref %build-inputs "btrfs-progs:static"))
+(out(assoc-ref %outputs "out"))
+(source (string-append btrfs "/bin/btrfs.static"))
+(target (string-append out "/bin/btrfs")))
+   (mkdir-p (dirname target))
+   (copy-file source target)
+   (remove-store-references target)
+   (chmod target #o555)
+(inputs `(("btrfs-progs:static" ,btrfs-progs "static")))
+(synopsis "Statically-linked btrfs command from btrfsprogs")
+(description
+ "This package provides statically-linked command of btrfs taken
+from the btrfsprogs package.  It is meant to be used in initrds.")
+(home-page (package-home-page btrfs-progs))
+(license (package-license btrfs-progs
+
 (define-public freefall
   (package
 (name "freefall")
-- 
2.9.0

Re: Preparing for 0.12.0

[Marius Bakke]

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 merging it next week.  If everything
>> > goes well, we can release after that.
>
> Yes, let's stick the schedule :)
>
>> A quick grep for 'replacement' digs up these grafts:
>> 
>> * cairo  (1059 rebuilds)
>> * curl   (1356 rebuilds)
>> * cyrus-sasl (1360 rebuilds)
>> * dbus   (1187 rebuilds)
>> * guile@2.0  (1457 rebuilds)
>> * libtiff(1672 rebuilds)
>> * libxslt(2765 rebuilds)
>> * pixman (1061 rebuilds)
>> * ruby   (344 rebuilds)
>> 
>> There is probably a fair bit of overlap between cairo, dbus and pixman.
>> Are these OK for staging? Ruby is an obvious candidate, I'll do that.
>
> I think it's okay to ungraft those packages on staging. Thanks Marius!

Done! I took the liberty of merging 'master' as well to get the recent
cairo graft. Luckily no conflicts. Also updated dbus to the latest
stable '1.10.14' (from 1.10.12).

Apparently ruby was already ungrafted.


signature.asc
Description: PGP signature

Re: New python build system merged

[Leo Famulari]

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=1#tabs-now-fail
> > 
> > Already there are several hundred new failures... I'm not sure what the
> > "root" failures are so far.
> 
> xorg-server "failed", but I think it's unrelated to the
> python-build-system changes:
> 
> https://hydra.gnu.org/build/1658774
> 
> The message at the end of the log:
> 
> guix build: error: failed to create GC root 
> `/home/hydra/offload-20121227-hydra.gnu.org-8762': File exists

I forgot to mention that I've restarted the xorg-server build in case
it's a transient error.

Re: New python build system merged

[Hartmut Goebel]

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. And have been too impatient.

> Already there are several hundred new failures... I'm not sure what the
> "root" failures are so far.

Some errors I checked are like this one:

@ build-succeeded 
/gnu/store/nzjcl8aviiz4643n13nn5vxfn540x1xb-xorg-server-1.18.4.drv -
guix build: error: failed to create GC root 
`/home/hydra/offload-20121227-hydra.gnu.org-8762': File exists
/gnu/store/j2pj0lhwwd430y5vfc6whrr5p4fc2b5m-xorg-server-1.18.4

Or even like this one
, which fail
with no visible error:

@ build-succeeded /gnu/store/i4dl6i1rz6pvcqhh5g70vqhbpa0nkswj-swig-3.0.5.drv -
/gnu/store/89rx3gby3b8f732alz3yrm0s78s0nnb8-swig-3.0.5

So hydra seems to have some problem, which makes it really hard to track
down issues.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: New python build system merged

[Leo Famulari]

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=1#tabs-now-fail
> 
> Already there are several hundred new failures... I'm not sure what the
> "root" failures are so far.

xorg-server "failed", but I think it's unrelated to the
python-build-system changes:

https://hydra.gnu.org/build/1658774

The message at the end of the log:

guix build: error: failed to create GC root 
`/home/hydra/offload-20121227-hydra.gnu.org-8762': File exists

Updater coverage

[Ludovic Courtès]

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---start->8---
$ ./pre-inst-env guix refresh libreoffice
gnu/packages/libreoffice.scm:711:2: warning: no updater for libreoffice
--8<---cut here---end--->8---

Another one is to show the actual package coverage:

--8<---cut here---start->8---
$ ./pre-inst-env guix refresh --list-updaters 
Available updaters:

  - gnu: Updater for GNU packages (6.3% coverage)
  - gnome: Updater for GNOME packages (3.3% coverage)
  - kde: Updater for KDE packages (1.5% coverage)
  - xorg: Updater for X.org packages (3.9% coverage)
  - kernel.org: Updater for packages hosted on kernel.org (.6% coverage)
  - elpa: Updater for ELPA packages (.2% coverage)
  - cran: Updater for CRAN packages (3.6% coverage)
  - bioconductor: Updater for Bioconductor packages (1.1% coverage)
  - hackage: Updater for Hackage packages (5.9% coverage)
  - pypi: Updater for PyPI packages (3.9% coverage)
  - gem: Updater for RubyGem packages (3.1% coverage)
  - github: Updater for GitHub packages (8.6% coverage)

42.1% of the packages are covered by these updaters.
--8<---cut here---end--->8---

42% is not a lot.  We could probably do 60% or so, notably by adding
updaters for CPAN, SourceForge, and Savannah.

I added the kernel.org updater and then realized that it only helps with
0.6% of the packages…

Next we should aim for more automation: automatic update of the list of
dependencies when possible (as Ricardo suggested), automatic build,
commit with the right log upon success and to the right branch based on
the number of rebuilds and/or submission as a patch.  This is far from
trivial but that should be our horizon.

Thoughts?

Ludo’.

Re: New python build system merged

[Leo Famulari]

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.
> 
> I strongly against reverting this! We already have a backlog of several
> python packages which are using "setuptools" as input. If reverting the
> new python build system, we need to clean them all up later.
> 
> We need to go forward instead of reverting. Fixing up the build issues
> should be easy since the changes are not fundamental.

Fair points, but the master branch is not where we put unfinished things
to be fixed.

This is the currently running evaluation (post-merge) compared with
before the merge:

https://hydra.gnu.org/eval/109381?compare=109380=1#tabs-now-fail

Already there are several hundred new failures... I'm not sure what the
"root" failures are so far.

Re: Preparing for 0.12.0

[Leo Famulari]

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 everything
> > goes well, we can release after that.

Yes, let's stick the schedule :)

> A quick grep for 'replacement' digs up these grafts:
> 
> * cairo  (1059 rebuilds)
> * curl   (1356 rebuilds)
> * cyrus-sasl (1360 rebuilds)
> * dbus   (1187 rebuilds)
> * guile@2.0  (1457 rebuilds)
> * libtiff(1672 rebuilds)
> * libxslt(2765 rebuilds)
> * pixman (1061 rebuilds)
> * ruby   (344 rebuilds)
> 
> There is probably a fair bit of overlap between cairo, dbus and pixman.
> Are these OK for staging? Ruby is an obvious candidate, I'll do that.

I think it's okay to ungraft those packages on staging. Thanks Marius!


signature.asc
Description: PGP signature

[PATCH 1/2] gnu: Add fcgi.

[Ricardo Wurmus]

* 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/fcgi-2.4.0-gcc44-fixes.patch | 14 
 gnu/packages/patches/fcgi-2.4.0-poll.patch| 89 +++
 gnu/packages/web.scm  | 25 +++
 4 files changed, 130 insertions(+)
 create mode 100644 gnu/packages/patches/fcgi-2.4.0-gcc44-fixes.patch
 create mode 100644 gnu/packages/patches/fcgi-2.4.0-poll.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index d9ec24a..a7d8fa2 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -539,6 +539,8 @@ dist_patch_DATA =   
\
   %D%/packages/patches/fasthenry-spUtils.patch \
   %D%/packages/patches/fasthenry-spSolve.patch \
   %D%/packages/patches/fasthenry-spFactor.patch\
+  %D%/packages/patches/fcgi-2.4.0-gcc44-fixes.patch\
+  %D%/packages/patches/fcgi-2.4.0-poll.patch   \
   %D%/packages/patches/findutils-localstatedir.patch   \
   %D%/packages/patches/findutils-test-xargs.patch  \
   %D%/packages/patches/flex-CVE-2016-6354.patch\
diff --git a/gnu/packages/patches/fcgi-2.4.0-gcc44-fixes.patch 
b/gnu/packages/patches/fcgi-2.4.0-gcc44-fixes.patch
new file mode 100644
index 000..0f921b1
--- /dev/null
+++ b/gnu/packages/patches/fcgi-2.4.0-gcc44-fixes.patch
@@ -0,0 +1,14 @@
+Taken from 
http://pkgs.fedoraproject.org/cgit/rpms/fcgi.git/plain/fcgi-2.4.0-gcc44_fixes.patch.
+Fixes compilation with GCC 4.4 and later.
+
+diff -up fcgi-2.4.0/libfcgi/fcgio.cpp.gcc44_fixes fcgi-2.4.0/libfcgi/fcgio.cpp
+--- fcgi-2.4.0/libfcgi/fcgio.cpp.gcc44_fixes   2002-02-24 21:12:22.0 
+0100
 fcgi-2.4.0/libfcgi/fcgio.cpp   2009-02-15 11:35:18.0 +0100
+@@ -23,6 +23,7 @@
+ #endif
+ 
+ #include 
++#include 
+ #include "fcgio.h"
+ 
+ using std::streambuf;
diff --git a/gnu/packages/patches/fcgi-2.4.0-poll.patch 
b/gnu/packages/patches/fcgi-2.4.0-poll.patch
new file mode 100644
index 000..73be6a0
--- /dev/null
+++ b/gnu/packages/patches/fcgi-2.4.0-poll.patch
@@ -0,0 +1,89 @@
+Taken from 
http://pkgs.fedoraproject.org/cgit/rpms/fcgi.git/plain/fcgi-2.4.0-poll.patch
+Fixes CVE-2012-6687.
+
+Author: Anton Kortunov 
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libfcgi/+bug/933417
+Description: use poll in os_unix.c instead of select to avoid problem with > 
1024 connections
+Forwarded: yes, fastcgi-develop...@mailman.fastcgi.com
+
+diff --git a/libfcgi/os_unix.c b/libfcgi/os_unix.c
+index 73e6a7f..af35aee 100755
+--- a/libfcgi/os_unix.c
 b/libfcgi/os_unix.c
+@@ -42,6 +42,7 @@ static const char rcsid[] = "$Id: os_unix.c,v 1.37 
2002/03/05 19:14:49 robs Exp
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #ifdef HAVE_NETDB_H
+ #include 
+@@ -103,6 +104,9 @@ static int volatile maxFd = -1;
+ static int shutdownPending = FALSE;
+ static int shutdownNow = FALSE;
+ 
++static int libfcgiOsClosePollTimeout = 2000;
++static int libfcgiIsAfUnixKeeperPollTimeout = 2000;
++
+ void OS_ShutdownPending()
+ {
+ shutdownPending = TRUE;
+@@ -168,6 +172,16 @@ int OS_LibInit(int stdioFds[3])
+ if(libInitialized)
+ return 0;
+ 
++char *libfcgiOsClosePollTimeoutStr = getenv( 
"LIBFCGI_OS_CLOSE_POLL_TIMEOUT" );
++if(libfcgiOsClosePollTimeoutStr) {
++libfcgiOsClosePollTimeout = atoi(libfcgiOsClosePollTimeoutStr);
++}
++
++char *libfcgiIsAfUnixKeeperPollTimeoutStr = getenv( 
"LIBFCGI_IS_AF_UNIX_KEEPER_POLL_TIMEOUT" );
++if(libfcgiIsAfUnixKeeperPollTimeoutStr) {
++libfcgiIsAfUnixKeeperPollTimeout = 
atoi(libfcgiIsAfUnixKeeperPollTimeoutStr);
++}
++
+ asyncIoTable = (AioInfo *)malloc(asyncIoTableSize * sizeof(AioInfo));
+ if(asyncIoTable == NULL) {
+ errno = ENOMEM;
+@@ -755,19 +769,16 @@ int OS_Close(int fd)
+ 
+ if (shutdown(fd, 1) == 0)
+ {
+-struct timeval tv;
+-fd_set rfds;
++struct pollfd pfd;
+ int rv;
+ char trash[1024];
+ 
+-FD_ZERO();
++pfd.fd = fd;
++pfd.events = POLLIN;
+ 
+ do 
+ {
+-FD_SET(fd, );
+-tv.tv_sec = 2;
+-tv.tv_usec = 0;
+-rv = select(fd + 1, , NULL, NULL, );
++rv = poll(, 1, libfcgiOsClosePollTimeout);
+ }
+ while (rv > 0 && read(fd, trash, sizeof(trash)) > 0);
+ }
+@@ -1116,13 +1127,11 @@ static int is_reasonable_accept_errno (const int error)
+  */
+ static int is_af_unix_keeper(const int fd)
+ {
+-struct timeval tval = { READABLE_UNIX_FD_DROP_DEAD_TIMEVAL };
+-fd_set read_fds;
+-
+-FD_ZERO(_fds);
+-FD_SET(fd, _fds);
++struct pollfd pfd;
++pfd.fd = fd;
++pfd.events = 

[PATCH 2/2] gnu: Add fcgiwrap.

[Ricardo Wurmus]

* 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,6 +226,41 @@ APIs.")
 ;; the Expat license, incompatible with the GPL.
 (license (l:non-copyleft "file://LICENSE.TERMS"
 
+(define-public fcgiwrap
+  (package
+(name "fcgiwrap")
+(version "1.1.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://github.com/gnosek/fcgiwrap/;
+   "archive/" version ".tar.gz"))
+   (file-name (string-append name "-" version ".tar.gz"))
+   (sha256
+(base32
+ "07y6s4mm86cv7p1ljz94sxnqa89y9amn3vzwsnbq5hrl4vdy0zac"
+(build-system gnu-build-system)
+(arguments
+ `(#:tests? #f ; no tests included
+   #:make-flags (list "CC=gcc")
+   #:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'bootstrap
+   (lambda _
+ (zero? (system* "autoreconf" "-vif")))
+(native-inputs
+ `(("autoconf" ,autoconf)
+   ("automake" ,automake)
+   ("pkg-config" ,pkg-config)))
+(inputs
+ `(("fcgi" ,fcgi)))
+(home-page "https://nginx.localdomain.pl/wiki/FcgiWrap;)
+(synopsis "Simple server for running CGI applications over FastCGI")
+(description "Fcgiwrap is a simple server for running CGI applications
+over FastCGI.  It hopes to provide clean CGI support to Nginx (and other web
+servers that may need it).")
+(license l:expat)))
+
 (define-public starman
   (package
 (name "starman")
-- 
2.10.2

Re: New python build system merged

[ng0]

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 very glad the new python build system is now in master. Thanks to
>>> everybody who helped finishing this!
>>>
>>> -- 
>>> Regards
>>> Hartmut Goebel
>>>
>>> | Hartmut Goebel  | h.goe...@crazy-compilers.com   |
>>> | www.crazy-compilers.com | compilers which you thought are impossible |
>>
>> Great job!
>>
>> So should I fix up all my ~70 or how many there are python
>> packages which I've sent in since september to get someone (or
>> hopefully multiple someones) to review them?
>
> Please do ping people.  Most likely the patch series fell into the
> cracks and only you can remind people of it.

Most likely, but there were also other issues. Like Harmut wanted
to do gunicorn while I was working on it at some point, so I
dropped that the series was forgotten. But I need to fix
conflicts anyway. I guess I can send in most of them by sunday,
there were also issues in many of the packages I need to
address. When I do this before people start to work on them it's
a bit easier to review as old issues aren't repeated.

I think most of them were in version-control, python,
networking, and it included the patches for kallithea, searx, and
some other software.

> I think Hartmut would be a good candidate to review them, Hartmut is our
> Python expert now.  :-)
>
> Ludo’.
>

-- 
♥Ⓐ  ng0  | ng0.chaosnet.org

Re: [PATCH] gnu: Add Kerberos client service.

[Andy Wingo]

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)
>> +(unless (or (not val) ((configuration-field-predicate 
>> field) val))
>>(configuration-field-error
>> (configuration-field-name field) val
>
> Here you’re assuming that when VAL is #f, it’s necessary invalid, an
> assumption that’s questionable and wasn’t made until now.
>
> Can you instead change your own field predicate to do that?

Agreed; the usual way to do this is to define the default value as a
sentinel value that your field predicate rejects.  E.g.

  (define unset-field (list 'unset-field))

You'd make the default value be `unset-field' (by reference).  Then
assuming you defined a field of type "foo" then assuming you have an
associated predicate `foo?', you can do

  (define (predicate/not-unset pred)
(lambda (x) (and (not (eq? x unset-field)) (pred x

  (define foo? (predicate/not-unset foo?))

Andy

Re: [PATCH] gnu: Add Kerberos client service.

[John Darrington]

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 changes.

ok.
 
 > +@subsubheading Krb5 Service
 > +
 > +The krb5 service provides the configuration for Kerberos clients, using
 > +the MIT implementation of the Kerberos protocol version@tie{}5.
 
 Please take into account my previous suggestions:
 
   https://lists.gnu.org/archive/html/guix-devel/2016-11/msg00922.html

ok
 
 
 Shouldn???t it be a single comma in @uref?  

I don't think so.  The Texinfo manual suggests, that in this case, the second 
arg
should be empty.
 
 >  (define (validate-configuration config fields)
 >(for-each (lambda (field)
 >(let ((val ((configuration-field-getter field) config)))
 > -(unless ((configuration-field-predicate field) val)
 > +(unless (or (not val) ((configuration-field-predicate 
field) val))
 >(configuration-field-error
 > (configuration-field-name field) val
 
 Here you???re assuming that when VAL is #f, it???s necessary invalid, an
 assumption that???s questionable and wasn???t made until now.

No.  I'm assuming the exact opposite, namely, that #f is a *valid* value.
 
 Can you instead change your own field predicate to do that?

I could do that, but then I'd be defining a lot of them which are substantially 
identical to existing ones - and below, you say that you don't want me to 
duplicate code ...
 
 > +
 > +(define (serialize-non-negative-integer field-name val)
 > +  (if val
 > +  (serialize-field* field-name val)))
 > +
 > +(define (serialize-integer field-name val)
 > +  (if val
 > +  (serialize-field* field-name val))
 
 No ???else??? here?  Looks like a bug.

No. The idea is, that if fields are #f then they output absolutely nothing.
 
 How much of this is copied from configuration.scm?  I don???t want
 duplicated code here.

Much of it was copied, but modified where appropriate.  None is identical
I don't think.
 
J'
 

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

We have no build system for Go

[ng0]

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
knowledge in Go would like to hack on this, we can provide input
and help on questions which might arise on Guix specific
behavior.

Consider this bug as an open invite for help.
Thanks,
-- 
♥Ⓐ  ng0  | ng0.chaosnet.org

Re: [PATCH] gnu: glibc-hurd: Force mach/hurd/libpthread subdirs to build first.

[Manolis Ragkousis]

Updated the patch with your suggestions, added you as a co-author and I
pushed it to core-updates.

Thank you,
Manolis

Re: [PATCH 1/2] gnu: Add Cuirass.

[Ludovic Courtès]

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’.

Re: [PATCH] gnu: Add Kerberos client service.

[Ludovic Courtès]

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 Kerberos clients, using
> +the MIT implementation of the Kerberos protocol version@tie{}5.

Please take into account my previous suggestions:

  https://lists.gnu.org/archive/html/guix-devel/2016-11/msg00922.html

> +@defvr {Scheme Variable} krb5-service-type
> +A service type for Kerberos 5 clients.

Ditto.

> +(service krb5-service-type (krb5-configuration
> + (default-realm "EXAMPLE.COM")

Ditto.

> +The @code{krb5-realm} and @code{krb5-configuration} types have many fields.
> +Only the most commonly used ones are described here.
> +For a full list, and more detailed explanation of each, see the MIT
> +@uref{http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html,,krb5.conf}
> +documentation.

Shouldn’t it be a single comma in @uref?  Also, @file{krb5.conf}.

> +@end deftp
> +
> +

Extra newline.

>  (define (validate-configuration config fields)
>(for-each (lambda (field)
>(let ((val ((configuration-field-getter field) config)))
> -(unless ((configuration-field-predicate field) val)
> +(unless (or (not val) ((configuration-field-predicate field) 
> val))
>(configuration-field-error
> (configuration-field-name field) val

Here you’re assuming that when VAL is #f, it’s necessary invalid, an
assumption that’s questionable and wasn’t made until now.

Can you instead change your own field predicate to do that?

> +(define (uglify-field-name field-name)
> +  (let ((str (symbol->string field-name)))
> +(string-join (string-split (if (string-suffix? "?" str)
> +   (substring str 0 (1- (string-length str)))
> +   str)
> +   #\-)
> + "_")))

Please add a docstring to explain what it does and/or an example.

> +(define (serialize-field* field-name val)
> +  (format #t "~a = ~a\n" (uglify-field-name field-name) val))
> +
> +(define (serialize-string field-name val)
> +  (if val
> +  (serialize-field* field-name val) ""))

Align both arms of the ‘if’.

> +;; An end-point is an address such as "192.168.0.1"
> +;; or an address port pair ("foo.example.com" . 109)
> +(define (end-point? val)
> +  (or (string? val)
> +  (and (pair? val)
> +   (string? (car val))
> +   (integer? (cdr val)

Rather:

  (define (end-point? val)
(match val
  ((? string?) #t)
  (((? string?) . (? integer?)) #t)
  (_ #f)))  ;do we need this catch-all case?

> +(define (serialize-end-point field-name val)
> +  (serialize-field* field-name
> +   (if (string? val)
> +   ;; The [] are needed in the case of IPv6 addresses
> +   (format #f "[~a]" val)
> +   (format #f "[~a]:~a" (car val) (cdr val)

No car/cdr please.

> +(define (serialize-space-separated-string-list field-name val)
> +  (if val
> +  (serialize-field* field-name (string-join val " "
> +
> +(define (comma-separated-string-list? val)
> +  (and (list? val)
> +   (and-map (lambda (x)
> +  (and (string? x) (not (string-index x #\,
> +val)))
> +
> +(define (serialize-comma-separated-string-list field-name val)
> +  (serialize-field* field-name (string-join val ",")))
> +
> +(define (comma-separated-integer-list? val)
> +  (and (list? val)
> +   (and-map (lambda (x) (integer? x))
> +val)))
> +
> +(define (serialize-comma-separated-integer-list field-name val)
> +  (if val
> +  (serialize-field* field-name
> +   (string-drop ; Drop the leading comma
> +(fold
> + (lambda (i prev)
> +   (string-append prev "," (number->string i)))
> + "" val) 1
> +
> +(define (file-name? val)
> +  (and (string? val)
> +   (string-prefix? "/" val)))
> +
> +(define (serialize-file-name field-name val)
> +  (serialize-string field-name val))
> +
> +
> +(define (serialize-boolean field-name val)
> +  (serialize-string field-name (if val "true" "false")))
> +
> +(define (non-negative-integer? val)
> +  (and (exact-integer? val) (not (negative? val
> +
> +(define (serialize-non-negative-integer field-name val)
> +  (if val
> +  (serialize-field* field-name val)))
> +
> +(define (serialize-integer field-name val)
> +  (if val
> +  (serialize-field* field-name val))

No ‘else’ here?  Looks like a bug.

> +(define (free-form-fields? val)
> +  (match val
> +(() #t)
> +? symbol?) . (? string)) . val) (free-form-fields? val))

Re: Preparing for 0.12.0

[David Craven]

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

Re: [PATCH] gnu: file-system-shepherd-service: Use mount-file-system.

[Ludovic Courtès]

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 equivalent to #t.

> +(mount-file-system
> + `(#$device #$title #$target #$type #$flags #$options
> +#$check?) #:root "/")
> #t))

#t must be align with the parent of “(mount-file-system”.

If you confirmed that at least “make check-system TESTS=basic” passes,
fine with me.

Thank you!

Ludo’.

Re: New python build system merged

[Ludovic Courtès]

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 is now in master. Thanks to
>> everybody who helped finishing this!
>>
>> -- 
>> Regards
>> Hartmut Goebel
>>
>> | Hartmut Goebel  | h.goe...@crazy-compilers.com   |
>> | www.crazy-compilers.com | compilers which you thought are impossible |
>
> Great job!
>
> So should I fix up all my ~70 or how many there are python
> packages which I've sent in since september to get someone (or
> hopefully multiple someones) to review them?

Please do ping people.  Most likely the patch series fell into the
cracks and only you can remind people of it.

I think Hartmut would be a good candidate to review them, Hartmut is our
Python expert now.  :-)

Ludo’.

Preparing for 0.12.0

[Ludovic Courtès]

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 week.  If everything
goes well, we can release after that.

How does that sound?

Thanks,
Ludo’.

Re: New python build system merged

[Ludovic Courtès]

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 to
> everybody who helped finishing this!

Woow, that was fast.  I was expecting a signal from you before we
trigger the merge button.

> However, Hartmut, I think that Build 1637640 is not even done building all 
> the packages yet (1853 packages are pending; and some "python-" packages are 
> in the queue), so it's anyone's guess which packages are affected.
>
> As for the Python-requiring packages (which do or don't have "python" in the 
> name), the failing ones I can spot are:
> - borg (can't import borg) 
> - calibre ("list index out of range" in setup.py)
> - kicad (because of python2-wxpython failure "option 
> --single-version-externally-managed not recognized")
> - python2-wxpython ("option --single-version-externally-managed not 
> recognized")
> - python-sympy (testing fails because some tests that were supposed to fail 
> passed instead)
> - python-ipython (Can't find "docs/build/texinfo/ipython.info")
> - python2-beautifulsoup4 (Tries to use "python3" in convert-py3k - why? After 
> all it's supposed to use Python 2)
>
> There are others.

Hartmut, can you look into these now?  I see Leo already fixed Borg and
hopefully the remaining issues are relatively easy to address.

Thanks!

Ludo’.

[PATCH] gnu: mesa: Update to 13.0.1.

[Marius Bakke]

* 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 deletions(-)

diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index 50b474c..850dfe1 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -196,7 +196,7 @@ also known as DXTn or DXTC) for Mesa.")
 (define-public mesa
   (package
 (name "mesa")
-(version "12.0.1")
+(version "13.0.1")
 (source
   (origin
 (method url-fetch)
@@ -204,7 +204,9 @@ also known as DXTn or DXTC) for Mesa.")
 version "/mesa-" version ".tar.xz"))
 (sha256
  (base32
-  "12b3i59xdn2in2hchrkgh4fwij8zhznibx976l3pdj3qkyvlzcms"
+  "0cd7axwihwsay0i9fvcw14cldbxyvf8b8rd5sh53plvppyr2z5ki"))
+(patches
+ (search-patches "mesa-wayland-egl-symbols-check-mips.patch"
 (build-system gnu-build-system)
 (propagated-inputs
   `(("glproto" ,glproto)
@@ -227,20 +229,10 @@ also known as DXTn or DXTC) for Mesa.")
 ("makedepend" ,makedepend)
 ("presentproto" ,presentproto)
 ("s2tc" ,s2tc)
-("udev" ,eudev)
 ("wayland" ,wayland)))
 (native-inputs
   `(("pkg-config" ,pkg-config)
-("python" ,python-2)
-
- ;; XXX To prevent a large number of rebuilds on other systems,
- ;; apply the following patch on MIPS systems only.  In the next
- ;; core-updates cycle, this patch could be applied on all platforms.
-,@(if (string-prefix? "mips" (or (%current-target-system)
- (%current-system)))
-  `(("mips-patch"
- ,(search-patch "mesa-wayland-egl-symbols-check-mips.patch")))
-  '(
+("python" ,python-2)))
 (arguments
  `(#:configure-flags
'(;; drop r300 from default gallium drivers, as it requires llvm
@@ -267,16 +259,6 @@ also known as DXTn or DXTC) for Mesa.")
   '("--with-dri-drivers=nouveau,r200,radeon,swrast"
#:phases
(modify-phases %standard-phases
- ;; Add an 'apply-mips-patch' phase conditionally (see above.)
- ,@(if (string-prefix? "mips" (or (%current-target-system)
-  (%current-system)))
-   `((add-after 'unpack 'apply-mips-patch
-   (lambda* (#:key inputs #:allow-other-keys)
- (let ((patch (assoc-ref inputs "mips-patch")))
-   (zero? (system* "patch" "-p1" "--force"
-   "--input" patch))
-   '())
-
  (add-after
'unpack 'patch-create_test_cases
(lambda _
-- 
2.10.2

Re: [PATCH] gnu: flex: Update to 2.6.2.

[David Craven]

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...

Re: Hosting a GuixSD server on commodity hosting platforms, a journey

[ng0]

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 if it just works.
Is there anyone who tried that before?

-- 
♥Ⓐ  ng0  | ng0.chaosnet.org

Re: New python build system merged

[Leo Famulari]

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 involving FUSE. They all fail as shown
below.

Is it expected for the build environment to have FUSE? They were skipped
with the old Python build system [0], so I've disabled them in
1d60f7c2b38733b031519a48771c44d20acb785d for
the time being.

[0] https://hydra.gnu.org/build/1648289/log#line-544

=== FAILURES ===
__ ArchiverTestCase.test_fuse __

self = 

@unittest.skipUnless(has_llfuse, 'llfuse not installed')
def test_fuse(self):
def has_noatime(some_file):
atime_before = os.stat(some_file).st_atime_ns
try:
os.close(os.open(some_file, flags_noatime))
except PermissionError:
return False
else:
atime_after = os.stat(some_file).st_atime_ns
noatime_used = flags_noatime != flags_normal
return noatime_used and atime_before == atime_after

self.cmd('init', self.repository_location)
self.create_test_files()
have_noatime = has_noatime('input/file1')
self.cmd('create', self.repository_location + '::archive', 'input')
self.cmd('create', self.repository_location + '::archive2', 'input')
if has_lchflags:
# remove the file we did not backup, so input and mount become equal
os.remove(os.path.join('input', 'flagfile'))
mountpoint = os.path.join(self.tmpdir, 'mountpoint')
# mount the whole repository, archive contents shall show up in 
archivename subdirs of mountpoint:
>   with self.fuse_mount(self.repository_location, mountpoint):

borg/testsuite/archiver.py:1042: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/gnu/store/alk9r3rir93pjmv8im20f8xrvv90219z-python-3.5.2/lib/python3.5/contextlib.py:59:
 in __enter__
return next(self.gen)
borg/testsuite/__init__.py:110: in fuse_mount
self.cmd(*args, fork=True)
borg/testsuite/archiver.py:235: in cmd
self.assert_equal(ret, exit_code)
E   AssertionError: 2 != 0
- Captured stdout call -
fuse: device not found, try 'modprobe fuse' first

Re: [PATCH] gnu: python-pip: Update to 9.0.1

[Hartmut Goebel]

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 version of setuptools
AFAIK. So this input can be removed at all.

Re: New python build system merged

[Danny Milosavljevic]

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.

However, Hartmut, I think that Build 1637640 is not even done building all the 
packages yet (1853 packages are pending; and some "python-" packages are in the 
queue), so it's anyone's guess which packages are affected.

As for the Python-requiring packages (which do or don't have "python" in the 
name), the failing ones I can spot are:
- borg (can't import borg) 
- calibre ("list index out of range" in setup.py)
- kicad (because of python2-wxpython failure "option 
--single-version-externally-managed not recognized")
- python2-wxpython ("option --single-version-externally-managed not recognized")
- python-sympy (testing fails because some tests that were supposed to fail 
passed instead)
- python-ipython (Can't find "docs/build/texinfo/ipython.info")
- python2-beautifulsoup4 (Tries to use "python3" in convert-py3k - why? After 
all it's supposed to use Python 2)

There are others.

On the other hand, many Python packages that failed building before now are 
working.
 
In any case I think the new Python build-system is an improvement and I can 
help fix some of those packages. Just don't merge when it's not even done 
building them yet :P