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

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Efraim Flashner  skribis:
>
>> On Wed, Nov 30, 2016 at 09:39:40PM -0500, Mark H Weaver wrote:
>>> 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
>>
>> It turns out libjpeg-turbo depends on nasm, which was incorrectly marked
>> as only supporting Intel hardware.
>
> Again, there’s no such problem on current master AFAICS:
>
> --8<---cut here---start->8---
> scheme@(guile-user)> ,use(guix)
> scheme@(guile-user)> ,use(gnu packages assembly)
> scheme@(guile-user)> ,use(gnu packages gnuzilla)
> scheme@(guile-user)> (package-supported-systems icecat)
> $15 = ("x86_64-linux" "i686-linux" "armhf-linux" "mips64el-linux")
> scheme@(guile-user)> (package-supported-systems nasm)
> $16 = ("x86_64-linux" "i686-linux" "armhf-linux" "mips64el-linux")
> scheme@(guile-user)> (package-transitive-supported-systems icecat)
> $17 = ("x86_64-linux" "i686-linux" "armhf-linux" "mips64el-linux")
> --8<---cut here---end--->8---

I believe that Efraim fixed the issue in commit
4181c9393d46bb8e24af1970c0e2adbcbfb2c639, shortly after my initial post
in this thread.

> and .

The URL above shows that the icecat jobs for armhf and mips64el were
removed, but that was before Efraim's fix.

 Thanks,
   Mark

Re: [PATCH] gnu: mesa: Update to 13.0.1.

[Ludovic Courtès]

Marius Bakke  skribis:

> Ludovic Courtès  writes:
>
>> Marius Bakke  skribis:
>>
>>> * 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.
>>
>> eudev was added in this commit:
>>
>>   commit ce4d7abf02627e990551c3bf0b67abfdf6725952
>>   Author: Mark H Weaver 
>>   Date:   Tue Dec 16 17:22:47 2014 -0500
>>
>>   gnu: mesa: Update to 10.4.0.
>>
>>   * gnu/packages/gl.scm (mesa): Update to 10.4.0.  Use current libdrm.  
>> Add
>> eudev, dri3proto, presentproto, and libxshmfence to inputs.  Add 
>> gnu-gettext
>> to native-inputs.  Add --enable-xa configure flag.  Add new phases
>> 'add-missing-m4-files' and 'patch-create_test_cases'.
>>
>> Are you sure it’s no longer necessary?  Mark?
>
> I removed eudev after reading the release notes for 13.0.0:
>
> http://mesa3d.org/relnotes/13.0.0.html
>
> (very bottom of page)

OK, thanks for confirming.

>> The parts about apply the MIPS patch is good to me.  Perhaps you can
>> already push it as a separate patch to ‘staging’.
>
> I can submit an update for 12.0.4 if the major version bump is too risky
> right now, or bump to 13.0.2 which was released three days ago. WDYT?

Go for 13.0.2 if you think it’s safe enough (the API doesn’t really
change I suppose, it’s “just OpenGL” no?), but better check a couple of
key packages reported by ‘guix package -l mesa’.

Thanks!

Ludo’.

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

[Ludovic Courtès]

Efraim Flashner  skribis:

> On Wed, Nov 30, 2016 at 09:39:40PM -0500, Mark H Weaver wrote:
>> 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
>
> It turns out libjpeg-turbo depends on nasm, which was incorrectly marked
> as only supporting Intel hardware.

Again, there’s no such problem on current master AFAICS:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(guix)
scheme@(guile-user)> ,use(gnu packages assembly)
scheme@(guile-user)> ,use(gnu packages gnuzilla)
scheme@(guile-user)> (package-supported-systems icecat)
$15 = ("x86_64-linux" "i686-linux" "armhf-linux" "mips64el-linux")
scheme@(guile-user)> (package-supported-systems nasm)
$16 = ("x86_64-linux" "i686-linux" "armhf-linux" "mips64el-linux")
scheme@(guile-user)> (package-transitive-supported-systems icecat)
$17 = ("x86_64-linux" "i686-linux" "armhf-linux" "mips64el-linux")
--8<---cut here---end--->8---

and .

Am I missing something?

Ludo’.

Re: i686 badly broken from premature 'python-build-system' merge

[Ludovic Courtès]

Mark H Weaver  skribis:

> I wrote:
>
>> I restarted [the yasm build] again.  Maybe it will work on the third
>> try.
>
> Indeed, the it worked on the third try, and the 'gdm' build on x86_64
> worked on the second try.  I'm restarting all dependency failures now.

Weird.  Thanks for the update.

Ludo’.

Re: gtk-doc build failure

[Marius Bakke]

Marius Bakke  writes:

> gtk-doc is not building in current 'master'. It seems to stem from
> python-build-system merge.

I've committed a workaround in 3cc0342b45406f97d675266cc9ac7877be855122.

There is a bug in the 'dblatex' setup.py manifesting when using the new
python-build-system. I don't know what causes it, but the problem seems
to be that the store paths in out/bin/.dblatex-real are wrong:

--- /gnu/store/k6211w9hlqyxvzhrsmh2a113rnzdqlkc-dblatex-0.3.5/bin/.dblatex-real 
1970-01-01 01:00:01.0 +0100
+++ /gnu/store/qx7wx5vhpjs5kgy876xdh2dqr1v5zd39-dblatex-0.3.5/bin/.dblatex-real 
1970-01-01 01:00:01.0 +0100
@@ -2,9 +2,9 @@
 import sys
 import os

-package_base = 
r"gnu/store/k6211w9hlqyxvzhrsmh2a113rnzdqlkc-dblatex-0.3.5/share/dblatex"
+package_base = 
r"/gnu/store/qx7wx5vhpjs5kgy876xdh2dqr1v5zd39-dblatex-0.3.5/share/dblatex"

-sys.path.append(r"gnu/store/k6211w9hlqyxvzhrsmh2a113rnzdqlkc-dblatex-0.3.5/lib/python2.7/site-packages")
+sys.path.append(r"/gnu/store/qx7wx5vhpjs5kgy876xdh2dqr1v5zd39-dblatex-0.3.5/lib/python2.7/site-packages")



signature.asc
Description: PGP signature

gtk-doc build failure

[Marius Bakke]

Hi,

gtk-doc is not building in current 'master'. It seems to stem from
python-build-system merge. I ran a bisect but had to skip a bunch of
commits due to subversion build failure. To save anyone else the
trouble, here is the result:

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
f3b98f4fec43c951a9e28c67561395992bf190a7
00e10c6e674f0f292d5821bc4a513d48f4d1d164
5d8549328483978bf04dd2c710ef6a06614d4776
5c31f4aa7c11fcf720c0ce0e26d55788e2df1044
f54d6bacbf46f5f25d3f7a5bea578879ee865be1
e442246a2f5f73b2484adb340b53d3a0018636b1
f210e94432fcb8d6c03589287833f7594f270522
891a843d5184f696618af6fcbb9791ef6b574504
d8013ee221bd599474340899ffb5974796091955
15e57f576291d9233ab25e1614c6218579db170a
b41a05ce497d5ecc682cf46ce61aa2215193f9f6
c1019287a4aab55ebffab4710b9a85b6c9f1b7ed
f22efa0152356da4755241de3726b6a254b49d11
b002f964bb3d69c77856ea7dcadfe82383050512
e7881f3db4dfddf46c3cd61ee684a2efd629ce1b
a2ff4f0240f0fac484836bb8ffb2f86917369666
dae73d9b9a4db932e8c7c1b7607981dc6cb401a5
482d95918e2a9de05ee224d979c15759e54febf0
5f7565d190cf380b7bae2ce12dba38aff98c4eb9
328bb95d3507682f5e06fb2880c632252f59ee57
46bcdcc287ecfc1db8b7a0429e72517f407b580d
7db40bce58e149ecb541d295e01cfbfe953d39a3
f2516de2fc7459d8ceed1779f0f24840075d08d6
b3e8b4bd0f390784c710944c9962a0e13b25ed02
We cannot bisect more!

Here is a good commit for testing (the build log of the test PDF is
different): aaf75c890b5242d3ab3671766226bc53ab07049a

Digging further... :-)


signature.asc
Description: PGP signature

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

[Mathieu Lirzin]

Hi,

Carlo Zancanaro  writes:

> On Thu, Dec 01 2016, ng0 wrote 
>> I tried that before (though I did just think it was wrong) and now I
>> get the same message as yesterday:
>>
>> ...
>>
>> In gnu/services/cuirass.scm:   81: 1 [cuirass-shepherd-service #] In
>> unknown file:?: 0 [string=? "" ((# # # # ...))]
>>
>> ERROR: In procedure string=?: ERROR: In procedure string=: Wrong
>> type argument in position 2 (expecting string): (((#:name . "guix")
>> (#:url . "git://git.savannah.gnu.org/guix.git") (#:load-path . ".")
>> (#:file . "/.../cuirass/tests/gnu-system.scm") (#:proc . hydra-jobs)
>> (#:arguments (subset . "hello")) (#:branch . "master")))
>
> It looks like cuirass is expecting the specifications to be a string,
> not a list. I don't know anything about cuirass, so I can't help you
> to configure the cuirass-service.
>
> Looking at the source, specifications has a comment ";string
> (file-name)". It looks like the "specifications" field of the
> configuration is just equivalent to the --specifications argument to the
> cuirass command, if that helps at all.

Indeed, this is a mistake on my side.  Here are 2 patches that should
fix this issue.

>From 707d6f7255eeab39b6694bc81537966cbca0e61d Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin 
Date: Thu, 1 Dec 2016 21:10:18 +0100
Subject: [PATCH 1/2] gnu: cuirass: Update to revision 2.

* gnu/packages/ci.scm (cuirass): Update to revision 2.
---
 gnu/packages/ci.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/ci.scm b/gnu/packages/ci.scm
index f07e75a..d88ee6d 100644
--- a/gnu/packages/ci.scm
+++ b/gnu/packages/ci.scm
@@ -185,8 +185,8 @@ their dependencies.")
   (license l:gpl3+
 
 (define-public cuirass
-  (let ((commit "7248c0038f3d0bfcf6c469d534efb4a13952c112")
-(revision "1"))
+  (let ((commit "05eba838eab4ca928d8df926d70677821714e962")
+(revision "2"))
 (package
   (name "cuirass")
   (version (string-append "0.0.1-" revision "." (string-take commit 7)))
@@ -198,7 +198,7 @@ their dependencies.")
 (file-name (string-append name "-" version))
 (sha256
  (base32
-  "0hkwh2pcz3wzg1n533ch2w7vwr97yr369q4ki0yqk99wfipjrydw"
+  "17bchil0dxflf74fncpr6drbpvc43a0hnvp22gp9w58kwpskwvri"
   (build-system gnu-build-system)
   (arguments
'(#:phases
-- 
2.10.2

>From ab369ae1b894bcbb4045aa70b30399543eb4b050 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin 
Date: Thu, 1 Dec 2016 20:41:08 +0100
Subject: [PATCH 2/2] services: cuirass: Put specifications in the store.

* gnu/services/cuirass.scm (): Change type of
'specifications' field to an alist to match the documentation example.
(cuirass-shepherd-service): Store the provided specifications in a file.  Use
that file as the "--specification" argument.
---
 gnu/services/cuirass.scm | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/gnu/services/cuirass.scm b/gnu/services/cuirass.scm
index d843c07..4975a7e 100644
--- a/gnu/services/cuirass.scm
+++ b/gnu/services/cuirass.scm
@@ -52,8 +52,8 @@
 (default 60))
   (database cuirass-configuration-database ;string (file-name)
 (default "/var/run/cuirass/cuirass.db"))
-  (specifications   cuirass-configuration-specifications ;string (file-name)
-(default ""))
+  (specifications   cuirass-configuration-specifications ;specification-alist
+(default '()))
   (use-substitutes? cuirass-configuration-use-substitutes? ;boolean
 (default #f))
   (one-shot?cuirass-configuration-one-shot? ;boolean
@@ -66,7 +66,7 @@
(let ((cache-directory  (cuirass-configuration-cache-directory config))
  (interval (cuirass-configuration-interval config))
  (database (cuirass-configuration-database config))
- (specifications   (cuirass-configuration-specifications config))
+ (specs(cuirass-configuration-specifications config))
  (use-substitutes? (cuirass-configuration-use-substitutes? config))
  (one-shot?(cuirass-configuration-one-shot? config)))
  (list (shepherd-service
@@ -78,9 +78,11 @@
 #$@(if (string=? "" cache-directory)
'()
(list "--cache-directory" cache-directory))
-#$@(if (string=? "" specifications)
+#$@(if (null? specs)
'()
-   (list "--specifications" specifications))
+   (let ((str (format #f "'~S" specs)))
+ (list "--specifications"
+   (plain-file "specs.scm" str
 

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

[Efraim Flashner]

On Wed, Nov 30, 2016 at 09:39:40PM -0500, Mark H Weaver wrote:
> 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

It turns out libjpeg-turbo depends on nasm, which was incorrectly marked
as only supporting Intel hardware. I think the hard thing is that, while
we can read the source and make guesses at fixing build errors, without
access to the hardware its hard to know if any changes made actually
result in a building package.

Anyway, Debian builds nasm on all architectures, so I removed that field
from the package. Looking back on the nasm thread, it looked like
everyone worked together to make the mistake :).

-- 
Efraim Flashner      אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

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

[Marius Bakke]

David Craven  writes:

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

Hi! I submitted a similar patch for fat32 support a while back and Ludo
suggested refactoring the  object to contain a
'check-procedure'. I got stuck at some point and have been
procrastinating since..

Attached is what I have so far. The biggest problem is that some callers
of 'check-file-system' does not use a  object, but see also
5970e8e24 which shows how to convert a loose spec to a .

I'll pick this back up, but testing and feedback welcome. Currently it
does not work at all :-)



signature.asc
Description: PGP signature
>From a222eb8781866e2b1dbb715f79acc91378e116c9 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Tue, 8 Nov 2016 21:33:34 +
Subject: [PATCH] file-systems: Refactor  to include
 check-procedure.

* gnu/system/file-systems.scm (file-system-check-procedure): New
variable.  Extend file-system record to include it.  Export it.
* gnu/build/file-systems.scm (check-file-system): Use it.
(mount-file-system): Serialize spec before calling check-file-system.
* gnu/build/linux-boot.scm: Adjust check-file-system arguments.
* gnu/services/base.scm: Likewise.
* gnu/system/linux-initrd.scm (base-initrd): Remove e2fsck/static from
helper-packages.
---
 gnu/build/file-systems.scm  | 24 +++-
 gnu/build/linux-boot.scm|  2 +-
 gnu/services/base.scm   |  8 +---
 gnu/system/file-systems.scm | 17 -
 gnu/system/linux-initrd.scm |  7 +--
 5 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/gnu/build/file-systems.scm b/gnu/build/file-systems.scm
index 0d55e91..e5053f5 100644
--- a/gnu/build/file-systems.scm
+++ b/gnu/build/file-systems.scm
@@ -410,27 +410,25 @@ 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 file-system)
+  "Run a file system check on FILE-SYSTEM."
+  (let* ((fsck   (file-system-check-procedure file-system))
+ (status (fsck device)))
 (match (status:exit-val status)
   (0
#t)
   (1
-   (format (current-error-port) "'~a' corrected errors on ~a; continuing~%"
-   fsck device))
+   (format (current-error-port) "'~a' corrected errors; continuing~%"
+   fsck))
   (2
-   (format (current-error-port) "'~a' corrected errors on ~a; rebooting~%"
-   fsck device)
+   (format (current-error-port) "'~a' corrected errors; rebooting~%"
+   fsck)
(sleep 3)
(reboot))
   (code
-   (format (current-error-port) "'~a' exited with code ~a on ~a; \
+   (format (current-error-port) "'~a' exited with code ~a; \
 spawning Bourne-like REPL~%"
-   fsck code device)
+   fsck code)
(start-repl %bournish-language)
 
 (define (mount-flags->bit-mask flags)
@@ -470,7 +468,7 @@ run a file system check."
(mount-point (string-append root "/" mount-point))
(flags   (mount-flags->bit-mask flags)))
(when check?
- (check-file-system source type))
+ (check-file-system (spec->file-system spec)))
 
;; Create the mount point.  Most of the time this is a directory, but
;; in the case of a bind mount, a regular file may be needed.
diff --git a/gnu/build/linux-boot.scm b/gnu/build/linux-boot.scm
index c34a3f7..903ce14 100644
--- a/gnu/build/linux-boot.scm
+++ b/gnu/build/linux-boot.scm
@@ -277,7 +277,7 @@ UNIONFS."
 ;; have to resort to 'pidof' here.
 (mark-as-not-killable (pidof unionfs)))
   (begin
-(check-file-system root type)
+(check-file-system root)
 (mount root "/root" type)))
 
   ;; Make sure /root/etc/mtab is a symlink to /proc/self/mounts.
diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index afbecdb..2c18e0a 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -273,13 +273,7 @@ FILE-SYSTEM."
#~#t)
  #$(if check?
#~(begin
-   ;; Make sure fsck.ext2 & co. can be found.
-   (setenv "PATH"
-   (string-append
-#$e2fsprogs "/sbin:"
-"/run/current-system/profile/sbin:"
-(getenv "PATH")))
-   (check-file-system device 

[PATCH] Downgrade psyclpc.

[ng0]

This applies: [PATCH] gnu: psyclpc: Downgrade to

The error is not obvious, as I did not submit an psyced package so far, 
otherwise people would complain about a broken xmpp functionality.

Re: [PATCH] gnu: mesa: Update to 13.0.1.

[Mark H Weaver]

Marius Bakke  writes:

> Ludovic Courtès  writes:
>
>> Marius Bakke  skribis:
>>
>>> * 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.
>>
>> eudev was added in this commit:
>>
>>   commit ce4d7abf02627e990551c3bf0b67abfdf6725952
>>   Author: Mark H Weaver 
>>   Date:   Tue Dec 16 17:22:47 2014 -0500
>>
>>   gnu: mesa: Update to 10.4.0.
>>
>>   * gnu/packages/gl.scm (mesa): Update to 10.4.0.  Use current libdrm.  
>> Add
>> eudev, dri3proto, presentproto, and libxshmfence to inputs.  Add 
>> gnu-gettext
>> to native-inputs.  Add --enable-xa configure flag.  Add new phases
>> 'add-missing-m4-files' and 'patch-create_test_cases'.
>>
>> Are you sure it’s no longer necessary?  Mark?
>
> I removed eudev after reading the release notes for 13.0.0:
>
> http://mesa3d.org/relnotes/13.0.0.html
>
> (very bottom of page)

Indeed, the release notes seem to indicate that 'eudev' can be removed
from 'inputs'.  Looks okay to me.

Thanks!
  Mark

Re: i686 badly broken from premature 'python-build-system' merge

[Mark H Weaver]

I wrote:

> I restarted [the yasm build] again.  Maybe it will work on the third
> try.

Indeed, the it worked on the third try, and the 'gdm' build on x86_64
worked on the second try.  I'm restarting all dependency failures now.

 Mark

Re: i686 badly broken from premature 'python-build-system' merge

[Mark H Weaver]

Hi Ludovic,

l...@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver  skribis:
>
>> yasm was apparently broken on i686 on the 'python-build-system' branch,
>> which was then subsequently merged into master.  As a result, many
>> important package are dependency-failures on i686, including all
>> gstreamer plugins, and thus all media players and web browsers.
>
> --8<---cut here---start->8---
> $ ./pre-inst-env guix build yasm -s i686-linux -K
> […]
> /gnu/store/7xv1zw247h3rlj8p6l95dz7frfypavcb-yasm-1.3.0
> $ git describe
> v0.11.0-3140-gd0b9c34
> --8<---cut here---end--->8---

Interesting.  Hydra tried to build it twice, and failed both times:

  https://hydra.gnu.org/build/1655354#tabs-buildsteps

I have saved logs from three build failures of 'yasm' on i686.  The
first one is from March 2016, and the other two are very recent.  There
are two tests that fail intermittently:

  FAIL: modules/objfmts/elf/tests/x32/elf_x32_test.sh
  FAIL: modules/objfmts/elf/tests/amd64/elf_amd64_test.sh

I also have saved logs from 'yasm' build failures on armhf and x86_64.
On armhf, the following test failed in July 2016:

  FAIL: modules/objfmts/elf/tests/gasx32/elf_gasx32_test.sh

and on x86_64, the following test failed in February 2016:

  FAIL: modules/objfmts/elf/tests/amd64/elf_amd64_test.sh

I restarted it again.  Maybe it will work on the third try.

> But now that I read Tobias message, I realize probably nasm is at fault,
> not yasm.

No.  Hydra indicates that 'yasm' is the reason for the important
dependency failures on i686:

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

Tobias may be right that 'nasm' is at fault for the non-Intel IceCat
jobs being removed, but that's apparently a different issue.

Note that there are also many new dependency failures on x86_64 due to a
build failure of 'gdm' on Hydra.  I guess that's yet another
non-deterministic build failure, since I managed to update my x86_64
system locally.

 Thanks,
   Mark

Re: [PATCH] gnu: mesa: Update to 13.0.1.

[Marius Bakke]

Ludovic Courtès  writes:

> Marius Bakke  skribis:
>
>> * 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.
>
> eudev was added in this commit:
>
>   commit ce4d7abf02627e990551c3bf0b67abfdf6725952
>   Author: Mark H Weaver 
>   Date:   Tue Dec 16 17:22:47 2014 -0500
>
>   gnu: mesa: Update to 10.4.0.
>
>   * gnu/packages/gl.scm (mesa): Update to 10.4.0.  Use current libdrm.  
> Add
> eudev, dri3proto, presentproto, and libxshmfence to inputs.  Add 
> gnu-gettext
> to native-inputs.  Add --enable-xa configure flag.  Add new phases
> 'add-missing-m4-files' and 'patch-create_test_cases'.
>
> Are you sure it’s no longer necessary?  Mark?

I removed eudev after reading the release notes for 13.0.0:

http://mesa3d.org/relnotes/13.0.0.html

(very bottom of page)

> The parts about apply the MIPS patch is good to me.  Perhaps you can
> already push it as a separate patch to ‘staging’.

I can submit an update for 12.0.4 if the major version bump is too risky
right now, or bump to 13.0.2 which was released three days ago. WDYT?


signature.asc
Description: PGP signature

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

[Tobias Geerinckx-Rice]

On 01/12/16 15:13, Tobias Geerinckx-Rice wrote:
> Most very likely my 7cba764 commit, ‘icecat: Use libjpeg-turbo instead
> of bundled libjpeg’[-turbo].

After some more poking around Hydra I might have been too eager to take
the blame for this. I'll keep an eye on it, though.

Kind regards,

T G-R



signature.asc
Description: OpenPGP digital signature

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

[Carlo Zancanaro]

On Thu, Dec 01 2016, ng0 wrote 
I tried that before (though I did just think it was wrong) and 
now I get the same message as yesterday:


...

In gnu/services/cuirass.scm: 
  81: 1 [cuirass-shepherd-service #] 
In unknown file: 
   ?: 0 [string=? "" ((# # # # ...))]


ERROR: In procedure string=?: ERROR: In procedure string=: Wrong 
type argument in position 2 (expecting string): (((#:name . 
"guix") (#:url . "git://git.savannah.gnu.org/guix.git") 
(#:load-path . ".") (#:file . 
"/.../cuirass/tests/gnu-system.scm") (#:proc . hydra-jobs) 
(#:arguments (subset . "hello")) (#:branch . "master")))


It looks like cuirass is expecting the specifications to be a 
string, not a list. I don't know anything about cuirass, so I 
can't help you to configure the cuirass-service.


Looking at the source, specifications has a comment ";string
(file-name)". It looks like the "specifications" field of the
configuration is just equivalent to the --specifications argument to the
cuirass command, if that helps at all.


signature.asc
Description: PGP signature

Re: i686 badly broken from premature 'python-build-system' merge

[Ludovic Courtès]

Mark H Weaver  skribis:

> yasm was apparently broken on i686 on the 'python-build-system' branch,
> which was then subsequently merged into master.  As a result, many
> important package are dependency-failures on i686, including all
> gstreamer plugins, and thus all media players and web browsers.

--8<---cut here---start->8---
$ ./pre-inst-env guix build yasm -s i686-linux -K
[…]
/gnu/store/7xv1zw247h3rlj8p6l95dz7frfypavcb-yasm-1.3.0
$ git describe
v0.11.0-3140-gd0b9c34
--8<---cut here---end--->8---

But now that I read Tobias message, I realize probably nasm is at fault,
not yasm.

Ludo’.

Re: [PATCH] gnu: texlive-texmf-minimal: Prune in snippet.

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Ricardo Wurmus  skribis:
>>>
 * gnu/packages/tex.scm (texlive-texmf-minimal)[arguments]: Move contents
 of "prune" build phase...
 [source]: ...to a snippet here.
>>>
>>> It looks nicer this way, but a possible downside is the extra derivation
>>> and recompression of the patched source.
>>>
>>> No strong opinion here though.
>>
>> My motivation was probably misguided.  My hope was that building
>> “texlive-texmf-minimal” would no longer require the very large download
>> of the full texlive-texmf sources but only the much smaller pruned
>> sources.  If this is the case I think it would be advantageous for
>> users.  However, if building from source would cause them to download
>> the big tarball first, then patch and repack, and then build the package
>> — that would obviously not be great.
>>
>> Do we provide substitutes for snippet-patched sources?
>
> Yes, as long as there’s a derivation, there’s a substitute.
>
> But really, we should get rid of this monolithic texlive and import
> individual CTAN packages, while still providing a big texlive
> meta-package for those who want the 4GiBs.

Yes, I agree.

I made the change when I was still hoping to be able to build the Python
science suite (numpy, scipy, matplotlib…) with texlive-minimal, which
turned out to fail in all instances.  It always missing a different tiny
subset of Texlive…

Texlive is one of the biggest annoyances here at the MDC.  The huge
package together with slow storage (and our users’ dependence on things
like numpy) means that I’m rebuilding Texlive for half a day each time I
update our shared Guix installation.  I’m *very* motivated to change
this.

I’ll build a CTAN (bulk) importer soon and will see where that leads us.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

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

[Tobias Geerinckx-Rice]

Mark

On 01/12/16 03:39, Mark H Weaver wrote:
> 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?

Most very likely my 7cba764 commit, ‘icecat: Use libjpeg-turbo instead
of bundled libjpeg’[-turbo].

The ‘libjpeg-turbo’ package depends on ‘nasm’, which I didn't realise
was only supported on x86.

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

I'll take a look. IceCat's bundled ‘libjpeg’ is really the (a?) -turbo
variant, so it shouldn't matter, but I obviously missed something.

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

While a valid sentiment, that's not what happened here.

Kind regards,

T G-R



signature.asc
Description: OpenPGP digital signature

Hydra replacement and all that

[Ludovic Courtès]

Leo Famulari  skribis:

> 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] ;)

I confirm the ETA!  :-)

Mathieu committed the Cuirass service for GuixSD yesterday, so now we
can adjust the config of the new machine to include that, and to have
nginx running in front of ‘guix publish’:

  http://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm

Not everyone is root on that machine, but everyone can contribute to the
config and test it.  Hint hint.  ;-)

Ludo’.

Re: New python build system merged

[Ludovic Courtès]

Leo Famulari  skribis:

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

It’s a transient error, a bug in the “old” offload implementation.

Ludo’.

Re: [PATCH] gnu: mesa: Update to 13.0.1.

[Ludovic Courtès]

Marius Bakke  skribis:

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

eudev was added in this commit:

  commit ce4d7abf02627e990551c3bf0b67abfdf6725952
  Author: Mark H Weaver 
  Date:   Tue Dec 16 17:22:47 2014 -0500

  gnu: mesa: Update to 10.4.0.

  * gnu/packages/gl.scm (mesa): Update to 10.4.0.  Use current libdrm.  Add
eudev, dri3proto, presentproto, and libxshmfence to inputs.  Add 
gnu-gettext
to native-inputs.  Add --enable-xa configure flag.  Add new phases
'add-missing-m4-files' and 'patch-create_test_cases'.

Are you sure it’s no longer necessary?  Mark?

The parts about apply the MIPS patch is good to me.  Perhaps you can
already push it as a separate patch to ‘staging’.

Thanks,
Ludo’.

Re: [PATCH] gnu: texlive-texmf-minimal: Prune in snippet.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>> Ricardo Wurmus  skribis:
>>
>>> * gnu/packages/tex.scm (texlive-texmf-minimal)[arguments]: Move contents
>>> of "prune" build phase...
>>> [source]: ...to a snippet here.
>>
>> It looks nicer this way, but a possible downside is the extra derivation
>> and recompression of the patched source.
>>
>> No strong opinion here though.
>
> My motivation was probably misguided.  My hope was that building
> “texlive-texmf-minimal” would no longer require the very large download
> of the full texlive-texmf sources but only the much smaller pruned
> sources.  If this is the case I think it would be advantageous for
> users.  However, if building from source would cause them to download
> the big tarball first, then patch and repack, and then build the package
> — that would obviously not be great.
>
> Do we provide substitutes for snippet-patched sources?

Yes, as long as there’s a derivation, there’s a substitute.

But really, we should get rid of this monolithic texlive and import
individual CTAN packages, while still providing a big texlive
meta-package for those who want the 4 GiBs.

Ludo’.

Re: [PATCH] gnu: Add uget.

[Ludovic Courtès]

Tomáš Čech  skribis:

> * gnu/packages/bittorrent.scm (uget): New variable.

You can add a copyright line for yourself in that file.

> +(license l:lgpl2.1)))

Version 2.1 only?

Otherwise LGTM, thanks!

Ludo’.

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

[ng0]

Carlo Zancanaro  writes:

> On Thu, Dec 01 2016, ng0 wrote
>> https://ptpb.pw/gQOZ.scm with this change it fails differently:
>
> This is wrong again, but for a different reason. The 
> `%desktop-services` must be the last argument to the `cons*` call.

I tried that before (though I did just think it was wrong) and
now I get the same message as yesterday:

ng0@greendragon ~$ sudo guix system build /etc/config.scm
Backtrace:
In ice-9/boot-9.scm:
1727: 19 [%start-stack load-stack ...]
1732: 18 [#]
In unknown file:
   ?: 17 [primitive-load 
"/gnu/store/vk6q4xahpy1dvs5ig3gg699fgszbf8ay-guix-0.11.0-4.1f41/bin/.guix-real"]
In guix/ui.scm:
1222: 16 [run-guix-command system "build" "/etc/config.scm"]
In ice-9/boot-9.scm:
 160: 15 [catch srfi-34 # ...]
 160: 14 [catch system-error ...]
In guix/scripts/system.scm:
 954: 13 [#]
 841: 12 [process-action build ("/etc/config.scm") ...]
In guix/store.scm:
1215: 11 [run-with-store # ...]
In guix/scripts/system.scm:
 853: 10 [# #]
 611: 9 [perform-action build # # ...]
In gnu/system.scm:
 635: 8 [operating-system-derivation # # #f]
In gnu/services.scm:
 585: 7 [loop #]
In srfi/srfi-1.scm:
 575: 6 [map # (# # #)]
In gnu/services.scm:
 585: 5 [loop #< type: # parameters: #>]
In srfi/srfi-1.scm:
 575: 4 [map # (# # # # ...)]
In gnu/services.scm:
 585: 3 [loop #< type: # parameters: ()>]
In srfi/srfi-1.scm:
 573: 2 [map # (# # # # 
...)]
In gnu/services/cuirass.scm:
  81: 1 [cuirass-shepherd-service #]
In unknown file:
   ?: 0 [string=? "" ((# # # # ...))]

ERROR: In procedure string=?:
ERROR: In procedure string=: Wrong type argument in position 2 (expecting 
string): (((#:name . "guix") (#:url . "git://git.savannah.gnu.org/guix.git") 
(#:load-path . ".") (#:file . "/.../cuirass/tests/gnu-system.scm") (#:proc . 
hydra-jobs) (#:arguments (subset . "hello")) (#:branch . "master")))


-- 
♥Ⓐ  ng0  | ng0.chaosnet.org

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

[Carlo Zancanaro]

On Thu, Dec 01 2016, ng0 wrote

https://ptpb.pw/gQOZ.scm with this change it fails differently:


This is wrong again, but for a different reason. The 
`%desktop-services` must be the last argument to the `cons*` call.


You want it to look like this (assuming my formatting comes out at 
least a little bit okay):


 (services (cons* (gnome-desktop-service)
  (tor-service)
  (console-keymap-service "de")
   (lsh-service)
   (let ((spec-guix `((#:name . "guix")
  (#:url . 
"git://git.savannah.gnu.org/guix.git")
  (#:load-path . ".")
  ;; Adapt to a valid absolute file name.
  (#:file . 
"/.../cuirass/tests/gnu-system.scm")
  (#:proc . hydra-jobs)
  (#:arguments (subset . "hello"))
  (#:branch . "master"

 (cuirass-service #:config (cuirass-configuration
(specifications (list 
spec-guix)
   %desktop-services))


signature.asc
Description: PGP signature

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

[ng0]

Sorry, I should really set up my client to add CC or even To with lists...

  Carlo Zancanaro  writes:

  > On Wed, Nov 30 2016, ng0 wrote
  >> Is there anything obvious I have to change?
  [ 6 more citation lines. Click/Enter to show. ]
  >
  > 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.)

  Thanks!

  https://ptpb.pw/gQOZ.scm with this change it fails differently:

  ng0@greendragon ~$ sudo guix system build /etc/config.scm
  Backtrace:
  In ice-9/boot-9.scm:
   160: 18 [catch #t # ...]
  In unknown file:
 ?: 17 [apply-smob/1 #]
  In ice-9/boot-9.scm:
66: 16 [call-with-prompt prompt0 ...]
  In ice-9/eval.scm:
   432: 15 [eval # #]
  In ice-9/boot-9.scm:
  2404: 14 [save-module-excursion #]
  4056: 13 [#]
  1727: 12 [%start-stack load-stack #]
  1732: 11 [#]
  In unknown file:
 ?: 10 [primitive-load 
"/gnu/store/vk6q4xahpy1dvs5ig3gg699fgszbf8ay-guix-0.11.0-4.1f41/bin/.guix-real"]
  In guix/ui.scm:
  1222: 9 [run-guix-command system "build" "/etc/config.scm"]
  In ice-9/boot-9.scm:
   160: 8 [catch srfi-34 # ...]
   160: 7 [catch system-error ...]
  In guix/scripts/system.scm:
   954: 6 [#]
   841: 5 [process-action build ("/etc/config.scm") ...]
  In guix/store.scm:
  1215: 4 [run-with-store # ...]
  In guix/scripts/system.scm:
   853: 3 [# #]
   611: 2 [perform-action build # # ...]
  In gnu/system.scm:
   635: 1 [operating-system-derivation # # #f]
  In unknown file:
 ?: 0 [append (# # # # ...) (# # # # ...)]

  ERROR: In procedure append:
  ERROR: In procedure append: Wrong type argument in position 1 (expecting 
empty list): #< type: #
  parameters: #< cache-directory: "" user: "cuirass" 
group: "cuirass" interval: 60 database: "/var/run/cuirass/cuirass.db"
  specifications: (((#:name . "guix") (#:url . 
"git://git.savannah.gnu.org/guix.git") (#:load-path . ".") (#:file .
  "/.../cuirass/tests/gnu-system.scm") (#:proc . hydra-jobs) (#:arguments 
(subset . "hello")) (#:branch . "master"))) use-substitutes?: #f
  one-shot?: #f>>

Re: i686 badly broken from premature 'python-build-system' merge

[Hartmut Goebel]

Am 01.12.2016 um 11:06 schrieb Mark H Weaver:
> yasm was apparently broken on i686 on the 'python-build-system' branch,

This error is not related to the python build system - until you proof
me wrong.

I've spend some time now for seeking the error (see below), until i
discovered that yasm is nor using the python build system at all. It is
not even using any python package beside "python-wrapper", which uses
the trivial build system and propagates "python".

Since I already did the analysis, here it is for the records:

I had a look at the source and I doubt this failure is related to the
python build system. I have no i686 system for testing this, though.

  *

Any error related to the new python build system would occur when
running any of the phases of the python build system. And even then
only calls to "setup.py" are effected. It is very uncommon that this
would happen in the middle of running the test suite.

  *

The error occurs only for one series: "elf-amd64 objfmt", whereas
all other series pass, e.g. "GAS elf-x86 objfmt". Both series call
the same test-wrapper "out_test.sh" which seem not to have an
case-handling for platforms. These two series only differ in the
paths of the input and output files and the options passed to yasm.
If this error would be related to the python build system, more if
not all test-cases would fail.

  *

The build log does not contain any entry related to python or
setup.py after the patch-shebang phase. So the python related stuff
seams not to be touched here.

-- 
Regards
Hartmut Goebel

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

[PATCH] gnu: Add grantlee.

[Thomas Danckaert]

>From 2a6447853b240887810459e06e6336b1d925756f Mon Sep 17 00:00:00 2001
From: Thomas Danckaert 
Date: Thu, 1 Dec 2016 12:25:38 +0100
Subject: [PATCH] gnu: Add grantlee.

* gnu/packages/qt.scm (grantlee): New variable.
---
 gnu/packages/qt.scm | 33 +
 1 file changed, 33 insertions(+)

diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index b442356..ae951aa 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -35,6 +35,7 @@
   #:use-module (gnu packages compression)
   #:use-module (gnu packages cups)
   #:use-module (gnu packages databases)
+  #:use-module (gnu packages documentation)
   #:use-module (gnu packages fontutils)
   #:use-module (gnu packages flex)
   #:use-module (gnu packages freedesktop)
@@ -59,6 +60,38 @@
   #:use-module (gnu packages xorg)
   #:use-module (gnu packages xml))
 
+(define-public grantlee
+  (package
+(name "grantlee")
+(version "5.1.0")
+(source
+  (origin
+(method url-fetch)
+(uri (string-append "https://github.com/steveire/grantlee/archive/v;
+version ".tar.gz"))
+(file-name (string-append name "-" version ".tar.gz"))
+(sha256
+ (base32 "1lf9rkv0i0kd7fvpgg5l8jb87zw8dzcwd1liv6hji7g4wlpmfdiq"
+(native-inputs
+ `(("doxygen" ,doxygen)))
+(inputs
+ `(("qtbase" ,qtbase)
+   ("qtscript" ,qtscript)))
+(build-system cmake-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (replace 'check
+  (lambda _
+(zero? (system* "ctest" ;; exclude 2 tests which require a display
+"-E" "htmlbuildertest|plainmarkupbuildertest")))
+(home-page "https://github.com/steveire/grantlee;)
+(synopsis "Libraries for text templating with Qt")
+(description "Grantlee Templates can be used for theming and generation of
+other text such as code.  The syntax uses the syntax of the Django template
+system, and the core design of Django is reused in Grantlee.")
+(license license:lgpl2.0+)))
+
 (define-public qt
   (package
 (name "qt")
-- 
2.7.4

[PATCH] gnu: Add libksysguard.

[Thomas Danckaert]

Hi Guix,

this patch adds libksysguard.  I put it in kde.scm, but it's actually 
a part of the plasma framework.  Should there be a separate module 
'gnu/packages/plasma.scm' for if/when more plasma packages get 
packaged?


Thomas
>From 2e9a25b4f99ee354ce226759396fcf806502faa1 Mon Sep 17 00:00:00 2001
From: Thomas Danckaert 
Date: Thu, 1 Dec 2016 11:56:20 +0100
Subject: [PATCH] gnu: Add libksysguard.

* gnu/packages/kde.scm (libksysguard): New variable.
---
 gnu/packages/kde.scm | 55 
 1 file changed, 55 insertions(+)

diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
index 82e7ed2..2e7e7b3 100644
--- a/gnu/packages/kde.scm
+++ b/gnu/packages/kde.scm
@@ -23,6 +23,8 @@
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix utils)
+  #:use-module (gnu packages compression)
+  #:use-module (gnu packages documentation)
   #:use-module (gnu packages kde-frameworks)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages tls)
@@ -85,7 +87,59 @@ used in KDE development tools Kompare and KDevelop.")
 ;; source archive
 (license (list license:gpl2+ license:lgpl2.0+ license:bsd-3
 
+(define-public libksysguard
+  (package
+(name "libksysguard")
+(version "5.8.2")
+(source
+  (origin
+(method url-fetch)
+(uri (string-append "mirror://kde//stable/plasma/" version
+"/libksysguard-" version ".tar.xz"))
+(sha256
+ (base32
+  "158n30wbpsgbw3axhhsc58hnwhwdd02j3zc9hhcybmnbkfl5c96l"
+(native-inputs
+ `(("extra-cmake-modules" ,extra-cmake-modules)
+   ("pkg-config" ,pkg-config)))
+(inputs
+ `(("kconfigwidgets" ,kconfigwidgets)
+   ("kiconthemes" ,kiconthemes)
+   ("kdbusaddons" ,kdbusaddons)
+   ("kdoctools" ,kdoctools)
+   ("kinit" ,kinit)
+   ("knewstuff" ,knewstuff)
+   ("knotifications" ,knotifications)
+   ("kwindowsystem" ,kwindowsystem)
+   ("kio" ,kio)
+   ("ki18n" ,ki18n)
+   ("kservice" ,kservice)
+   ("qtbase" ,qtbase)
+   ("qtscript" ,qtscript)
+   ("qtwebkit" ,qtwebkit)
+   ("qtx11extras" ,qtx11extras)
+   ("plasma" ,plasma-framework)
+   ("zlib" ,zlib)))
+(build-system cmake-build-system)
+(arguments
+ `(#:configure-flags
+   `(,(string-append "-DKDE_INSTALL_DATADIR=" (assoc-ref %outputs "out") "/share"))
+   #:phases
+   (modify-phases %standard-phases
+ (add-before 'configure 'patch-cmakelists
+ (lambda _
+   (substitute* "processcore/CMakeLists.txt"
+ (("KAUTH_HELPER_INSTALL_DIR") "KDE_INSTALL_LIBEXECDIR"
+ (replace 'check
+  (lambda _ ;; other tests require a display and therefore fail
+(zero? (system* "ctest" "-R" "chronotest")))
+(home-page "https://www.kde.org/info/plasma-5.8.2.php;)
+(synopsis "Network enabled task and system monitoring")
+(description "KSysGuard can obtain information on system load and
+manage running processes.  It obtains this information by interacting
+with a ksysguardd daemon, which may also run on a remote system.")
+(license license:gpl3+)))
+
 (define-public qca
   (package
 (name "qca")
-- 
2.7.4

Re: i686 badly broken from premature 'python-build-system' merge

[Hartmut Goebel]

Am 01.12.2016 um 11:06 schrieb Mark H Weaver:
> yasm was apparently broken on i686 on the 'python-build-system' branch,

Can you please send me the ./test-suite.log. Given only the information
in the build log it is very hard to find the reason.

-- 
Regards
Hartmut Goebel

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

i686 badly broken from premature 'python-build-system' merge

[Mark H Weaver]

Hi,

yasm was apparently broken on i686 on the 'python-build-system' branch,
which was then subsequently merged into master.  As a result, many
important package are dependency-failures on i686, including all
gstreamer plugins, and thus all media players and web browsers.

This branch should not have been merged until these issues were fixed.
Now, i686 users won't be able to get important security updates such as
the recent icecat fixes (for which there are active exploits seen in the
wild) in a timely fashion.

 Mark

Re: [PATCH] gnu: Add varnish.

[Ricardo Wurmus]

Marius Bakke  writes:

> Ricardo Wurmus  writes:
>
>>> + (add-after 'install 'wrap-binary
>>> +   (lambda* (#:key inputs outputs #:allow-other-keys)
>>> + (let* ((out (assoc-ref outputs "out"))
>>> +(varnishd (string-append out "/sbin/varnishd"))
>>> +(PATH (string-append (assoc-ref inputs "binutils") 
>>> "/bin"))
>>> +(LIBRARY_PATH (string-append (assoc-ref inputs 
>>> "glibc") "/lib")))
>>> +   ;; Add binutils to PATH so gcc finds the 'as' executable.
>>> +   (wrap-program varnishd
>>> + `("PATH" ":" prefix (,PATH)))
>>> +   ;; Without this, we get an error such as "ld: cannot find 
>>> crti.o"
>>> +   ;; when compiling VCL.
>>> +   (wrap-program varnishd
>>> + `("LIBRARY_PATH" ":" prefix (,LIBRARY_PATH)))
>>> +   #t))
>>
>> What is VCL?  Is it always compiled from scratch at runtime?
>
> VCL is the Varnish Configuration Language. The configuration file is
> compiled at startup and when loading other configs at runtime. It is
> also possible to have inline C code in the VCL.
>
>>
>>> +(inputs
>>> + `(("binutils" ,binutils)
>>> +   ("gcc" ,gcc)
>>> +   ("glibc" ,glibc/linux)
>>
>> These three inputs are implicitly available as native inputs when using
>> the gnu-build-system.  Should varnish get a gcc-toolchain as a runtime
>> input instead of these three separate inputs?
>
> How would this work? Importing (gnu packages commencement) in web.scm
> causes a bunch of "unbound variable" errors, probably due to conflicting
> package names.
>
> The 'as' requirement is actually from gcc, which should preferably be
> compiled with '--with-as=' (but does not
> currently have binutils as input). I was surprised it used 'ld', which
> probably works as a side effect after wrapping the binutils PATH.
>
> The "LIBRARY_PATH" hack should possibly be fixed in binutils as well.
>
> A custom toolchain sounds like a cleaner approach than these two
> workarounds since those quirks can be worked out there, but not sure how
> to go about making it.

Okay, thanks for explaining this.  About the problems with “as” and
“binutils” could you please also send a bug report to bug-g...@gnu.org?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net