bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

[Christopher Allan Webber]

Ludovic Courtès writes:

> Christopher Allan Webber <cweb...@dustycloud.org> skribis:
>
>> If I reboot into GuixSD, at some point in the boot process it resets my
>> hardware clock to 1970!  If I reboot into Debian again after that, it's
>> 1970 there also.
>
> Ouch!  Your config includes the ntp daemon.  Could it be that it’s
> misbehaving?
>
> You can remove it along the lines of:
>
>   (define %my-desktop-services
> (remove (lambda (service)
>   (eq? (service-kind service) ntp-service-type))
> %desktop-services))
>
> Well, you need to export ‘ntp-service-type’ from (gnu services
> networking) first…
>
> Other than that, I have no idea what could be resetting the hardware
> clock to 0.

So I did this, and it stopped resetting the hardware clock for Debian as
well when I rebooted into Guix.  It also makes me think that there's no
reason we should have ntp-service-type in %desktop-services, though
that's a separate issue.

So that's part 1 resolved, I think.  Part 2 is the problem that even
though Debian now keeps the right time while rebooting from Debian ->
GuixSD -> Debian, GuixSD still doesn't know what time it is... or that
is, doesn't know what time it is on the most recent system build!  It
turns out my 0.9.0 system build still works correctly.

Not only that, but I verified that my friend Aeva hits the *same*
"problem" and "solution"...!


*** Most recent Guix system (Linux-Libre 4.3.3) ***

bash-4.3$ date
Wed Dec 31 18:01:42 CST 1969
bash-4.3$ sudo hwclock -r
hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: Invalid 
argument

(NOTE: aeva did not hit the hwclock -r ... but she also did not do
"hwclock -w" from Debian (she did it from GuixSD instead))


*** Initial Guix system (Linux-Libre 4.2.5) ***

bash-4.3$ date
Sat Jan  2 20:39:30 CST 2016
bash-4.3$ sudo hwclock -r
Sun 03 Jan 2016 02:39:48 AM America  .821300 seconds


In both Aeva and I's systems, the hardware clock could not be read (and
thus we got 1969) in the most recent system built and installed by
GuixSD, but in the original system install (from Guix 0.9.0), the clock
works just fine.

Thus my *guess* is that this is a regression in the kernel (either that
or we both "added" some mistake) between 4.2.5 and 4.3.3.

When I'm not on a train I can try building the "current" system with
Linux-Libre 4.2.5 and see if it's really the kernel.

Looks like we're on the right track to sorting this out!
 - Chris

bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

[Christopher Allan Webber]

Mark H Weaver writes:

> Very strange.  FWIW, I've used Libreboot X60 and X200 laptops running
> GuixSD quite extensively -- they are my primary development machines --
> and I've never seen anything like this.
>
> One possibility that comes to mind is that perhaps your hardware clock
> battery is dead, and that sometimes Debian is able to hide that fact by
> setting the date via NTP or something.  Can you try running "hwclock -r"
> after a cold boot into Debian and see what it says?

Yes it isn't the battery.  I've also verified that this happens on my
friend Aeva's minifree x200 w/ Libreboot + Guix.  More on that in my
next email.

>> Any idea what could be causing this?  I noticed that if I rebooted it
>> at the time that it asked me for a passphrase to decrypt /home/ that it
>> didn't reset the clock, though maybe I should test that again.
>
> If you're sharing /home between Debian and GuixSD, I wonder if going
> back and forth between two different versions of GNOME while sharing the
> data in dot-files/directories is causing a problem?
>
> This in turn makes me wonder if the clock is truly being reset during
> the GuixSD boot process, or if it might be happening during login to
> your desktop environment.  Please try the following:
>
> * Cold boot into Debian.
> * Set the hardware clock (hwclock -w).
> * Read the hardware clock to verify that it works (hwclock -r).
> * Reboot into GuixSD.
> * Log in to a text console as root and check both the system clock
>   (date) and the hardware clock (hwclock -r).
>
>  Thanks,
>Mark

I've done this and I ran into problems still.  However, I think I
figured out the source of them... I suspect there were two problems.
I'll detail in my reply to Ludovic.

bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

[Christopher Allan Webber]

Hello,

I recently installed GuixSD on the laptop I got fresh from Minifree.  I
was happy to see how much worked, but I've noticed a bug that occurs in
GuixSD but not in Debian.

In Debian I can set the hardware clock (with `hwclock -w`) and if I
reboot back into Debian again, I still have the same hardware clock.

If I reboot into GuixSD, at some point in the boot process it resets my
hardware clock to 1970!  If I reboot into Debian again after that, it's
1970 there also.

This is fairly serious, because this could greatly mess up committing to
git, running makefiles, or simply knowing when I wrote that file to
disk.  Also, ssl certs no longer validate, etc.

Any idea what could be causing this?  I noticed that if I rebooted it
at the time that it asked me for a passphrase to decrypt /home/ that it
didn't reset the clock, though maybe I should test that again.

My system config file is attached.

;; This is an operating system configuration template
;; for a "desktop" setup with X11.

(use-modules (gnu) (gnu system nss))
(use-service-modules desktop)
(use-package-modules xfce ratpoison certs)

(operating-system
  (host-name "oolong")
  (timezone "America/Chicago")
  (locale "en_US.UTF-8")

  ;; Assuming /dev/sdX is the target hard disk, and "root" is
  ;; the label of the target root file system.
  (bootloader (grub-configuration
   (device "/dev/sda")))
  (mapped-devices (list (mapped-device
 (source "/dev/sda8")
 (target "home-luks")
 (type luks-device-mapping
  (file-systems `(,(file-system
(device "guix")
(title 'label)
(mount-point "/")
(type "ext4"))
  ,(file-system
 (device "/dev/mapper/home-luks")
 (mount-point "/home")
 (type "ext4"))
  ,@%base-file-systems))

  (users (cons (user-account
(name "cwebber")
(uid 1000)
(comment "Christopher Allan Webber")
(group "cwebber")
(supplementary-groups '("users"
"wheel" "netdev"
"audio" "video"))
(home-directory "/home/cwebber"))
   %base-user-accounts))

  (groups (cons (user-group
 (name "cwebber")
 (id 1000))
%base-groups))

  ;; Add Xfce and Ratpoison; that allows us to choose
  ;; sessions using either of these at the log-in screen.
  (packages (cons* xfce ratpoison;desktop environments
   nss-certs ;for HTTPS access
   %base-packages))

  ;; Use the "desktop" services, which include the X11
  ;; log-in service, networking with Wicd, and more.
  (services %desktop-services)

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss))

bug#22883: Authenticating a Git checkout

[Christopher Allan Webber]

Ludovic Courtès writes:

>>> Second, even if it did, it would be a shallow check: as Mike notes in
>>>  with the ‘signchk’
>>> script, you actually have to traverse the whole commit history and
>>> authenticate them one by one.  But that’s OK, it runs in presumably less
>>> than a minute on a repo the size of Guix’s, and we could also stop at
>>> signed tags to avoid redundant checks.
>>
>> Practically speaking, that's probably fine, though note that a signed
>> tag is just a signed hash of the commit it points to (with some
>> metadata), so you're trusting the integrity of SHA-1 and nothing
>> more.
>>
>> With that said, the tag points to what will hopefully be a signed
>> commit, so if you verify the signature of the tag _and_ that commit,
>> that'd be even better.  Git's use of SHA-1 makes cryptographic
>> assurances difficult/awkward.
>>
>> An occasional traversal of the entire DAG by, say, a CI script would
>> provide some pretty good confidence.  I wouldn't say it's necessary for
>> every pull.
>
> Agreed.

One theoretical optimization: if I verify the DAG, could I store
somewhere that I've verified from commit cabba6e and upward already, so
the next time I verify it only has to verify the new commits?

Mostly makes sense if we're already going down the only mildly
crazypants direction of implementing our own tooling :)

 - Chris

bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

[Christopher Allan Webber]

Christopher Allan Webber writes:

> Ludovic Courtès writes:
>
>> Christopher Allan Webber <cweb...@dustycloud.org> skribis:
>>
>>> My config is attached.  Hackily, I copy-pasta'ed the kernel packages
>>> entirely from guix v0.9.0's release.  I can confirm that this can read
>>> the hardware clock just fine, whereas the other version of the kernel
>>> can't... so it does indeed look like between Linux-Libre 4.2.5 and
>>> Linux-Libre 4.3.3 we have some sort of regression that leads to this
>>> problem on x200 Minifree Libreboot-enabled laptops, at least.
>>
>> Great, thanks for narrowing it down.
>>
>> Given that, I think it would be useful to keep a copy of 4.2.5 in Guix
>> itself.  Would you like to provide a patch for that, preferably using
>> ‘(inherit linux-libre)’ rather than copying the whole recipe?
>>
>> Ludo’.
>
> Yes, I will work on this.

Here's a patch that does just this.  Does it look good enough to merge?

>From afcd19c4b3cf69ecacf2c34ba3051fc05c830879 Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber <cweb...@dustycloud.org>
Date: Sun, 17 Jan 2016 20:34:25 -0800
Subject: [PATCH] gnu: Add linux-libre-4.2.5

This older version of linux-libre is being added because it was found
that newer versions (or at least 4.3.3) of linux-libre were not reading
the hardware clock on (at least Libreboot-enabled) Thinkpad x200
machines.

* gnu/linux.scm (linux-libre-4.2.5): New variable.
---
 gnu/packages/linux.scm | 16 
 1 file changed, 16 insertions(+)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 779b9c8..de4d1bd 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -317,6 +317,22 @@ It has been modified to remove all non-free binary blobs.")
 (license license:gpl2)
 (home-page "http://www.gnu.org/software/linux-libre/;
 
+;; This older version of linux-libre is being added because it was found
+;; that newer versions (or at least 4.3.3) of linux-libre were not reading
+;; the hardware clock on (at least Libreboot-enabled) Thinkpad x200
+;; machines.
+
+(define-public linux-libre-4.2.5
+  (package
+(inherit linux-libre)
+(version "4.2.5")
+(source (origin
+ (method url-fetch)
+ (uri (linux-libre-urls version))
+ (sha256
+  (base32
+   "13ar9sghm2g5w2km9x2d07q3lh81rz286d6slklv56qanm24chzx"))
+
 
 ;;;
 ;;; Pluggable authentication modules (PAM).
-- 
2.1.4

bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

[Christopher Allan Webber]

Ludovic Courtès writes:

> Christopher Allan Webber <cweb...@dustycloud.org> skribis:
>
>> From e60db8323c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001
>> From: Christopher Allan Webber <cweb...@dustycloud.org>
>> Date: Sun, 17 Jan 2016 20:34:25 -0800
>> Subject: [PATCH] gnu: Add linux-libre-4.2.5
>>
>> This older version of linux-libre is being added because it was found
>> that newer versions (or at least 4.3.3) of linux-libre were not reading
>> the hardware clock on (at least Libreboot-enabled) Thinkpad x200
>> machines.
>
> Since this text is available as a comment, I think it’s not necessary to
> keep it here.

Okay, removed.

>> * gnu/linux.scm (linux-libre-4.2.5): New variable.
>  
> Typo.  :-)

Ha!  Unintentional joke... :)

>> +;; This older version of linux-libre is being added because it was found
>> +;; that newer versions (or at least 4.3.3) of linux-libre were not reading
>> +;; the hardware clock on (at least Libreboot-enabled) Thinkpad x200
>> +;; machines.
>
> Maybe add “See <http://bugs.gnu.org/22274>.”
>
> Other than that, if it builds, it’s all good!  :-)
>
> Thank you,
> Ludo’.

Great, I made those changes and pushed it!  I'm using it already! :)

bug#22633: Provide a kvm-less qemu / guix system vm

[Christopher Allan Webber]

Ludovic Courtès writes:

> Jookia <166...@gmail.com> skribis:
>
>> We should probably also blacklist kvm on Libreboot machines too somehow,
>
> A simple way to achieve this is with:
>
>   (operating-system
> ;; …
> (kernel-arguments '("modprobe.blacklist=kvm-intel,kvm")))

I tried this:

  (operating-system
(kernel linux-libre-4.1)
(kernel-arguments '("modprobe.blacklist=kvm-intel,kvm"))
...)

The generated Grub configuration looks right:

  menuentry "GNU with Linux-Libre 4.1.17 (alpha)" {
search --label --set guix
linux 
/gnu/store/k3l4g22vypwniy0k3f8xha9l8p1s716d-linux-libre-4.1.17/bzImage 
--root=guix --system=/gnu/store/flq2702dmj6ppqc4iix6xgp0q364yl3l-system 
--load=/gnu/store/flq2702dmj6ppqc4iix6xgp0q364yl3l-system/boot 
modprobe.blacklist=kvm-intel,kvm
initrd /gnu/store/flq2702dmj6ppqc4iix6xgp0q364yl3l-system/initrd
  }

Unfortunately, after rebooting into it:

  cwebber@oolong:~$ lsmod | grep kvm
  kvm_intel 155648  0
  kvm   491520  1 kvm_intel
  cwebber@oolong:~$ ls /dev/kvm
  /dev/kvm

Not sure why it didn't seem to do anything...

> But I guess ‘guix system vm’ will now fail.
>
> We could change the two occurrences of ‘-enable-kvm’ to use this flag if
> and only if /dev/kvm exists (I think it doesn’t exist when the kvm
> modules are not loaded.)

If we could really get kvm blocked, I could write this patch.

> Thoughts?
>
> Ludo’.

bug#22633: Provide a kvm-less qemu / guix system vm

[Christopher Allan Webber]

Leo Famulari writes:

> On Fri, Feb 12, 2016 at 09:50:09AM +1100, Jookia wrote:
>> On Thu, Feb 11, 2016 at 09:26:12AM -0800, Christopher Allan Webber wrote:
>> > So on my Libreboot-enabled machine, KVM does not work.  In fact, even
>> > starting qemu with KVM enabled on it appears to crash my whole system.
>> > Not only does "guix system vm" not work, even "guix system vm-image" can
>> > take the whole machine down!
>> 
>> Currently the 'solution' I've found is to edit Guix to remove the two 
>> instances
>> of '--enable-kvm' which works somewhat, though it's slower as there's 
>> absolutely
>> no acceleration.
>> 
>> > It would be nice to have a --no-kvm switch, because I'd really like to
>> > make use of Guix's nice VM features!
>
> It's not a proper fix, but this patch achieves that on my non-Libreboot
> machine. Can you see if it works for you?
>
> [...]

Good news there, that does work and I am able to boot a VM through that
route!

I would really like to be able to protect myself from accidentally
crashing my system by making sure that if /dev/kvm is not there that we
don't do --enable-kvm, so maybe I could do that if we can figure out how
to make blacklisting actually work.  In the meanwhile, maybe I should
add a --no-kvm flag to "guix system vm"?

bug#22633: Provide a kvm-less qemu / guix system vm

[Christopher Allan Webber]

Jookia writes:

> On Mon, Feb 22, 2016 at 11:35:30AM -0800, Christopher Allan Webber wrote:
>>#~(string-append
>> - " -enable-kvm -no-reboot -net nic,model=virtio \
>> + ;; Only enable kvm if we see /dev/kvm exists.
>> + ;; This allows uers without hardware virtualization to still use these
>> + ;; commands.
>> + #$(if (file-exists? "/dev/kvm")
>> +   " -enable-kvm "
>> +   "")
>> + " -no-reboot -net nic,model=virtio \
>>" #$@(map virtfs-option shared-fs) " \
>>-net user \
>>-serial stdio -vga std \
>> -- 
>> 2.6.3
>
> What if I enable KVM then run the script?
>
> Jookia.

Then it should use KVM.

bug#22633: Provide a kvm-less qemu / guix system vm

[Christopher Allan Webber]

Christopher Allan Webber writes:

> Ludovic Courtès writes:
>
>> Libkmod honors ‘modprobe.blacklist’ (in ‘kcmdline_parse_result’ in
>> libkmod-config.c) and eudev passes KMOD_PROBE_APPLY_BLACKLIST
>> unconditionally in udev-builtin-kmod.c (meaning it honors it too.)
>>
>> However, there’s a hyphen-vs-underscore issue, I think.  Namely, the
>> file is called ‘kvm-intel.ko’, but the normalized module name is
>> ‘kvm_intel’, and this is what libkmod expects (commit 5c7dd5a changes
>> our code to normalize module names similarly.)
>>
>> Could you try with “modprobe.blacklist=kvm_intel”?
>
> I tried it, and it works!  This does mean that /dev/kvm doesn't exist,
> so I should be able to write a patch to Guix that disables kvm for qemu
> when /dev/kvm is absent.  Great! :)

This is slightly based off of Leo's preliminary patch, so I included him
in the copyright headers.  I've tested and it works (in terms of
disabling kvm if no /dev/kvm is present) here.

Let me know if I need to fix something or if I should push...

>From 852e0049213a0a80cacdcad4aba13ab242c3fbd8 Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber <cweb...@dustycloud.org>
Date: Mon, 22 Feb 2016 11:23:14 -0800
Subject: [PATCH] vm: Only pass "-enable-kvm" to qemu if /dev/kvm is present.

* gnu/build/vm.scm (load-in-linux-vm): Only pass "-enable-kvm" flag to qemu
  if "/dev/kvm" is present.
* gnu/system/vm.scm (common-kvm-options): Same as above.
---
 gnu/build/vm.scm  | 19 ++-
 gnu/system/vm.scm | 10 +-
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/gnu/build/vm.scm b/gnu/build/vm.scm
index a095f9d..823156d 100644
--- a/gnu/build/vm.scm
+++ b/gnu/build/vm.scm
@@ -1,5 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013, 2014, 2015 Ludovic Courtès <l...@gnu.org>
+;;; Copyright © 2016 Christopher Allan Webber <cweb...@dustycloud.org>
+;;; Copyright © 2016 Leo Famulari <l...@famulari.name>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -97,7 +99,7 @@ the #:references-graphs parameter of 'derivation'."
 (_ #f))
 
   (unless (zero?
-   (apply system* qemu "-enable-kvm" "-nographic" "-no-reboot"
+   (apply system* qemu "-nographic" "-no-reboot"
   "-m" (number->string memory-size)
   "-net" "nic,model=virtio"
   "-virtfs"
@@ -111,10 +113,17 @@ the #:references-graphs parameter of 'derivation'."
   "-initrd" initrd
   "-append" (string-append "console=ttyS0 --load="
builder)
-  (if make-disk-image?
-  `("-drive" ,(string-append "file=" image-file
- ",if=virtio"))
-  '(
+  (append
+   (if make-disk-image?
+   `("-drive" ,(string-append "file=" image-file
+  ",if=virtio"))
+   '())
+   ;; Only enable kvm if we see /dev/kvm exists.
+   ;; This allows uers without hardware virtualization to still use these
+   ;; commands.
+   (if (file-exists? "/dev/kvm")
+   '("-enable-kvm")
+   '()
 (error "qemu failed" qemu))
 
   (if make-disk-image?
diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index a7c03bd..5235ee3 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -1,5 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013, 2014, 2015, 2016 Ludovic Courtès <l...@gnu.org>
+;;; Copyright © 2016 Christopher Allan Webber <cweb...@dustycloud.org>
+;;; Copyright © 2016 Leo Famulari <l...@famulari.name>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -457,7 +459,13 @@ with '-virtfs' options for the host file systems listed in SHARED-FS."
  "\" "))
 
   #~(string-append
- " -enable-kvm -no-reboot -net nic,model=virtio \
+ ;; Only enable kvm if we see /dev/kvm exists.
+ ;; This allows uers without hardware virtualization to still use these
+ ;; commands.
+ #$(if (file-exists? "/dev/kvm")
+   " -enable-kvm "
+   "")
+ " -no-reboot -net nic,model=virtio \
   " #$@(map virtfs-option shared-fs) " \
   -net user \
   -serial stdio -vga std \
-- 
2.6.3

bug#22633: Provide a kvm-less qemu / guix system vm

[Christopher Allan Webber]

Ludovic Courtès writes:

> Christopher Allan Webber <cweb...@dustycloud.org> skribis:
>
>> Christopher Allan Webber writes:
>>
>>> Ludovic Courtès writes:
>>>
>>>> Libkmod honors ‘modprobe.blacklist’ (in ‘kcmdline_parse_result’ in
>>>> libkmod-config.c) and eudev passes KMOD_PROBE_APPLY_BLACKLIST
>>>> unconditionally in udev-builtin-kmod.c (meaning it honors it too.)
>>>>
>>>> However, there’s a hyphen-vs-underscore issue, I think.  Namely, the
>>>> file is called ‘kvm-intel.ko’, but the normalized module name is
>>>> ‘kvm_intel’, and this is what libkmod expects (commit 5c7dd5a changes
>>>> our code to normalize module names similarly.)
>>>>
>>>> Could you try with “modprobe.blacklist=kvm_intel”?
>>>
>>> I tried it, and it works!  This does mean that /dev/kvm doesn't exist,
>>> so I should be able to write a patch to Guix that disables kvm for qemu
>>> when /dev/kvm is absent.  Great! :)
>>
>> This is slightly based off of Leo's preliminary patch, so I included him
>> in the copyright headers.  I've tested and it works (in terms of
>> disabling kvm if no /dev/kvm is present) here.
>
> Cool!  Can you just double-check whether -enable-kvm has any effect when
> /dev/kvm is missing?  If it has no effect when /dev/kvm is missing, then
> we don’t even need a patch.

I checked yes; qemu fails.

>> Let me know if I need to fix something or if I should push...
>>
>> From 852e0049213a0a80cacdcad4aba13ab242c3fbd8 Mon Sep 17 00:00:00 2001
>> From: Christopher Allan Webber <cweb...@dustycloud.org>
>> Date: Mon, 22 Feb 2016 11:23:14 -0800
>> Subject: [PATCH] vm: Only pass "-enable-kvm" to qemu if /dev/kvm is present.
>>
>> * gnu/build/vm.scm (load-in-linux-vm): Only pass "-enable-kvm" flag to qemu
>>   if "/dev/kvm" is present.
>> * gnu/system/vm.scm (common-kvm-options): Same as above.
>
> [...]
>
>> +   ;; Only enable kvm if we see /dev/kvm exists.
>> +   ;; This allows uers without hardware virtualization to 
>> still use these
>  ^^
> Typo.
>
> [...]
>
>> + ;; Only enable kvm if we see /dev/kvm exists.
>> + ;; This allows uers without hardware virtualization to still use these
>
> Ditto.

Okay, fixed those.

> Otherwise the patch LGTM.  Make sure to mention:
>
>   Fixes <http://bugs.gnu.org/22633>.
>
> in the commit log.

Mentioned, committed, pushed!

bug#22633: Provide a kvm-less qemu / guix system vm

[Christopher Allan Webber]

Ludovic Courtès writes:

> Libkmod honors ‘modprobe.blacklist’ (in ‘kcmdline_parse_result’ in
> libkmod-config.c) and eudev passes KMOD_PROBE_APPLY_BLACKLIST
> unconditionally in udev-builtin-kmod.c (meaning it honors it too.)
>
> However, there’s a hyphen-vs-underscore issue, I think.  Namely, the
> file is called ‘kvm-intel.ko’, but the normalized module name is
> ‘kvm_intel’, and this is what libkmod expects (commit 5c7dd5a changes
> our code to normalize module names similarly.)
>
> Could you try with “modprobe.blacklist=kvm_intel”?

I tried it, and it works!  This does mean that /dev/kvm doesn't exist,
so I should be able to write a patch to Guix that disables kvm for qemu
when /dev/kvm is absent.  Great! :)

bug#22808: Add a function to simplify many of the new python2-foo definitions

[Christopher Allan Webber]

Right now we have a lot of these that look very similar:

  (define-public python2-chardet
(package
  (inherit (package-with-python2
(strip-python2-variant python-chardet)))
  (native-inputs `(("python2-setuptools" ,python2-setuptools)

  (define-public python2-translitcodec
(package
  (inherit (package-with-python2
(strip-python2-variant python-translitcodec)))
  (native-inputs `(("python2-setuptools" ,python2-setuptools)

  (define-public python2-celery
(let ((celery (package-with-python2
   (strip-python2-variant python-celery
  (package
(inherit celery)
(native-inputs `(("python2-setuptools" ,python2-setuptools)
 ("python2-unittest2" ,python2-unittest2)
 ("python2-mock" ,python2-mock)
 ,@(package-native-inputs celery))

Time for an abstraction?

bug#22858: Patch security vulnerability in python-pillow

[Christopher Allan Webber]

See: https://lwn.net/Articles/677914/

> Package: pillow
> CVE ID : CVE-2016-0740 CVE-2016-0775 CVE-2016-2533 
> 
> Multiple security vulnerabilities have been found in Pillow, a Python
> imaging library, which may result in denial of service or the execution
> of arbitrary code if a malformed FLI, PCD or Tiff files is processed.
> 
> For the oldstable distribution (wheezy), this problem has been fixed
> in version 1.1.7-4+deb7u2 of the python-imaging source package.
> 
> For the stable distribution (jessie), this problem has been fixed in
> version 2.6.1-2+deb8u2.
> 
> For the testing distribution (stretch), this problem has been fixed
> in version 3.1.1-1.
> 
> For the unstable distribution (sid), this problem has been fixed in
> version 3.1.1-1.
> 
> We recommend that you upgrade your pillow packages.
> 
> Further information about Debian Security Advisories, how to apply
> these updates to your system and frequently asked questions can be
> found at: https://www.debian.org/security/

I'm trying to figure out where the patches for this are, but I can't
find them.  I expected them to maybe be here, but I don't see them here:

  http://sources.debian.net/patches/pillow/3.1.1-1/

bug#22858: Patch security vulnerability in python-pillow

[Christopher Allan Webber]

Leo Famulari writes:

>> I'm trying to figure out where the patches for this are, but I can't
>> find them.  I expected them to maybe be here, but I don't see them here:
>
> I updated python-pillow to 3.1.1 with 16095d2729, fixing these issues.
>
> When I did that, CVE-2016-2533 wasn't named yet, but my understanding is
> that the update does address it:
> https://github.com/python-pillow/Pillow/commits/e5324bd3b4195d68d4a066b16d912fca30d3c4be
>
> Python2-pil *is* vulnerable. However, it seems to have no users in our
> source tree. Should we remove it?

I think so.  Here's a patch to remove it.  Look good?  (Not sure if this
needs a review or not :))

 - Chris

>From cbeb28d364bf2df3ef95c547b80830611254fd5c Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber <cweb...@dustycloud.org>
Date: Mon, 29 Feb 2016 14:36:01 -0800
Subject: [PATCH] gnu: Remove python2-pil.

* gnu/packages/python.scm (python2-pil): Remove variable.  It is vulnerable to
  CVE-2016-2533, and python2-pillow provides equivalent functionality, so this
  package can be cleanly removed.
---
 gnu/packages/python.scm | 61 -
 1 file changed, 61 deletions(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 812aeb0..4f34537 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -4596,67 +4596,6 @@ converts incoming documents to Unicode and outgoing documents to UTF-8.")
   (strip-python2-variant python-beautifulsoup4)))
 (native-inputs `(("python2-setuptools" ,python2-setuptools)
 
-(define-public python2-pil
-  (package
-(name "python2-pil")
-(version "1.1.7")
-(source
-  (origin
-(method url-fetch)
-(uri (string-append
-  "http://effbot.org/downloads/Imaging-;
-  version ".tar.gz"))
-(sha256
-  (base32
-"04aj80jhfbmxqzvmq40zfi4z3cw6vi01m3wkk6diz3lc971cfnw9"))
-   (modules '((guix build utils)))
-   (snippet
-;; Adapt to newer freetype. As the package is unmaintained upstream,
-;; there is no use in creating a patch and reporting it.
-'(substitute* "_imagingft.c"
-   (("freetype/")
-"freetype2/")
-(build-system python-build-system)
-(inputs
-  `(("freetype" ,freetype)
-("libjpeg" ,libjpeg)
-("libtiff" ,libtiff)
-("python-setuptools" ,python-setuptools)
-("zlib" ,zlib)))
-(arguments
- ;; Only the fork python-pillow works with Python 3.
- `(#:python ,python-2
-   #:tests? #f ; no check target
-   #:phases
- (alist-cons-before
-  'build 'configure
-  ;; According to README and setup.py, manual configuration is
-  ;; the preferred way of "searching" for inputs.
-  ;; lcms is not found, TCL_ROOT refers to the unavailable tkinter.
-  (lambda* (#:key inputs #:allow-other-keys)
-(let ((jpeg (assoc-ref inputs "libjpeg"))
-  (zlib (assoc-ref inputs "zlib"))
-  (tiff (assoc-ref inputs "libtiff"))
-  (freetype (assoc-ref inputs "freetype")))
-  (substitute* "setup.py"
-(("JPEG_ROOT = None")
- (string-append "JPEG_ROOT = libinclude(\"" jpeg "\")"))
-(("ZLIB_ROOT = None")
- (string-append "ZLIB_ROOT = libinclude(\"" zlib "\")"))
-(("TIFF_ROOT = None")
- (string-append "TIFF_ROOT = libinclude(\"" tiff "\")"))
-(("FREETYPE_ROOT = None")
- (string-append "FREETYPE_ROOT = libinclude(\""
-freetype "\")")
-  %standard-phases)))
-(home-page "http://www.pythonware.com/products/pil/;)
-(synopsis "Python Imaging Library")
-(description "The Python Imaging Library (PIL) adds image processing
-capabilities to the Python interpreter.")
-(license (x11-style
-   "file://README"
-   "See 'README' in the distribution."
-
 (define-public python2-cssutils
   (package
 (name "python2-cssutils")
-- 
2.6.3

bug#22858: Patch security vulnerability in python-pillow

[Christopher Allan Webber]

Christopher Allan Webber writes:

> Leo Famulari writes:
>
>>> I'm trying to figure out where the patches for this are, but I can't
>>> find them.  I expected them to maybe be here, but I don't see them here:
>>
>> I updated python-pillow to 3.1.1 with 16095d2729, fixing these issues.
>>
>> When I did that, CVE-2016-2533 wasn't named yet, but my understanding is
>> that the update does address it:
>> https://github.com/python-pillow/Pillow/commits/e5324bd3b4195d68d4a066b16d912fca30d3c4be
>>
>> Python2-pil *is* vulnerable. However, it seems to have no users in our
>> source tree. Should we remove it?
>
> I think so.  Here's a patch to remove it.  Look good?  (Not sure if this
> needs a review or not :))
>
>  - Chris

Leo gave me some comments on the description on IRC, so I changed those
and pushed!

bug#22139: Indirect dependencies are not grafted

[Christopher Allan Webber]

Mark Weaver laid out a plan that he thinks would work on IRC a couple of
years ago, and referenced it yesterday on #guix.  Here it is:
  https://gnunet.org/bot/log/guix/2014-09-25#T480219

Some further conversation:
  https://gnunet.org/bot/log/guix/2014-10-27#T502706

bug#22626: Postgres service fails on adding user

[Christopher Allan Webber]

Heya all... guix system config attached.  I tried doing a guix system
reconfigure and it failboat'ed.  Here's what happened:

  adding user 'postgres'...
  useradd: group 'postgres' does not exist
  Backtrace:
  In ice-9/boot-9.scm:
63: 19 [call-with-prompt prompt0 ...]
  In ice-9/eval.scm:
   432: 18 [eval # #]
  In ice-9/boot-9.scm:
  2401: 17 [save-module-excursion #]
  4050: 16 [#]
  1724: 15 [%start-stack load-stack ...]
  1729: 14 [#]
  In unknown file:
 ?: 13 [primitive-load 
"/gnu/store/24mbii9wjlyzfzsqwfmcvz6vz2fv5n6g-guix-0.9.0.c3f29bc/bin/.guix-real"]
  In guix/ui.scm:
  1177: 12 [run-guix-command system "reconfigure" "guix-config.scm"]
  In ice-9/boot-9.scm:
   157: 11 [catch srfi-34 # ...]
   157: 10 [catch system-error ...]
  In guix/scripts/system.scm:
   701: 9 [process-action reconfigure ("guix-config.scm") ...]
  In guix/store.scm:
  1061: 8 [run-with-store # ...]
  In guix/scripts/system.scm:
   520: 7 [# #]
   302: 6 [# #]
  In unknown file:
 ?: 5 [primitive-load 
"/gnu/store/fnanaa7xalxa9h3yh1hpj3m5zgm9wasp-activate"]
  In ice-9/eval.scm:
   432: 4 [eval # ()]
  In ice-9/boot-9.scm:
   768: 3 [for-each # #]
  In unknown file:
 ?: 2 [primitive-load 
"/gnu/store/hz2hnin6c12afvsyqxv0vs2rndxl9vpg-activate-servic
  e"]
  In ice-9/eval.scm:
   411: 1 [eval # ()]
  In unknown file:
 ?: 0 [getpw "postgres"]
  
  ERROR: In procedure getpw:
  ERROR: In procedure getpw: entry not found

Config attached.  Thanx!
 - cwebb



guix-config.scm
Description: Binary data

bug#22633: Provide a kvm-less qemu / guix system vm

[Christopher Allan Webber]

So on my Libreboot-enabled machine, KVM does not work.  In fact, even
starting qemu with KVM enabled on it appears to crash my whole system.
Not only does "guix system vm" not work, even "guix system vm-image" can
take the whole machine down!

It would be nice to have a --no-kvm switch, because I'd really like to
make use of Guix's nice VM features!

PS: Apparently in future revisions of Libreboot, this will be fixed.
  For now though...

bug#22626: Postgres service fails on adding user

[Christopher Allan Webber]

Ludovic Courtès writes:

> Christopher Allan Webber <cweb...@dustycloud.org> skribis:
>
>> Heya all... guix system config attached.  I tried doing a guix system
>> reconfigure and it failboat'ed.  Here's what happened:
>>
>>   adding user 'postgres'...
>>   useradd: group 'postgres' does not exist
>
> Normally just above that there should be:
>
>   adding group 'postgres'
>
> Could it be that adding the group silently failed?  What does /etc/group
> shows?

Well, it looks like it does do that.  I didn't show my full output
because there's a lot of garbage... maybe it turns out that this garbage
is related:

The following derivation will be built:
   /gnu/store/kil0p7xg6qrvvkf3mp0j0xii09s1cqx7-grub.cfg.drv
/gnu/store/qsgrb7inl2mkrnccxf524faqax63dbs4-system
/gnu/store/1b31ydr0yrc3jdl6i4chaccsbapzq0m5-grub.cfg
/gnu/store/sx2xqvr3s033bl60s09zs6jjbs73n791-grub-2.00
activating system...
setting up setuid programs in '/run/setuid-programs'...
populating /etc from /gnu/store/piaczch5x7vczy9z7yjq4z8631rh828p-etc...
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
adding group 'postgres'...
groupadd: existing lock file /etc/group.lock without a PID
groupadd: cannot lock /etc/group; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
adding user 'ntpd'...
useradd: existing lock file /etc/group.lock without a PID
useradd: cannot lock /etc/group; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: no changes
usermod: no changes
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
usermod: existing lock file /etc/shadow.lock without a PID
usermod: cannot lock /etc/shadow; try again later.
adding user 'postgres'...
useradd: group 'postgres' does not exist

Anyway /etc/group does not show postgres but I suppose it wouldn't
without the "guix system reconfigure" succeeding?

> (When testing in ‘guix system vm’, everything works well.)

I can't tell whether or not "guix system vm" would be fine; I assume it
probably would because I got to the point where qemu must have been
invoked, since my system crashed.  See my last bug.

It definitely does not work with "guix system reconfigure" though.

bug#22876: Python can't use https with recent grafts

[Christopher Allan Webber]

Most of Guix seems to be working just fine with the grafts support and
grafting of openssl.  However, unlike most grafts that will be done
probably, this one removes a feature, and that seems to be creating
problems in Python land.

  >>> from urllib.request import HTTPSHandler
  Traceback (most recent call last):
File "", line 1, in 
  ImportError: cannot import name 'HTTPSHandler'

Notably, virtualenv no longer works:

  $ guix environment --ad-hoc python-virtualenv
  substitute: updating list of substitutes from 'http://hydra.gnu.org'... 100.0%
  The following derivations will be built:
 /gnu/store/mcxrh4ba9pf4855kcbdnz654r0xxf86b-profile.drv
 /gnu/store/ii3ykjkidhz88ycx4p3gi2c7bhhn1vqz-ca-certificate-bundle.drv
 /gnu/store/h6fzjn70ki8vk3sxd0863vqjwkds1723-info-dir.drv

  $ virtualenv /tmp/try-virtualenv
  Using base prefix '/gnu/store/1spkp48cbbzg6ic5qkv3qpm3mvsgwkys-python-3.4.3'
  New python executable in /tmp/try-virtualenv/bin/python
  Installing setuptools, pip, wheel...
Complete output from command /tmp/try-virtualenv/bin/python -c "import sys, 
pip; sys...d\"] + sys.argv[1:]))" setuptools pip wheel:
Traceback (most recent call last):
File "", line 1, in 
File 
"/gnu/store/h38982xp00s1g95nzr6lws31w8q8njb3-python-virtualenv-13.1.2/lib/python3.4/site-packages/virtualenv-13.1.2-py3.4.egg/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/__init__.py",
 line 15, in 
File 
"/gnu/store/h38982xp00s1g95nzr6lws31w8q8njb3-python-virtualenv-13.1.2/lib/python3.4/site-packages/virtualenv-13.1.2-py3.4.egg/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/vcs/subversion.py",
 line 9, in 
File 
"/gnu/store/h38982xp00s1g95nzr6lws31w8q8njb3-python-virtualenv-13.1.2/lib/python3.4/site-packages/virtualenv-13.1.2-py3.4.egg/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/index.py",
 line 30, in 
File 
"/gnu/store/h38982xp00s1g95nzr6lws31w8q8njb3-python-virtualenv-13.1.2/lib/python3.4/site-packages/virtualenv-13.1.2-py3.4.egg/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/wheel.py",
 line 35, in 
File 
"/gnu/store/h38982xp00s1g95nzr6lws31w8q8njb3-python-virtualenv-13.1.2/lib/python3.4/site-packages/virtualenv-13.1.2-py3.4.egg/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/_vendor/distlib/scripts.py",
 line 14, in 
File 
"/gnu/store/h38982xp00s1g95nzr6lws31w8q8njb3-python-virtualenv-13.1.2/lib/python3.4/site-packages/virtualenv-13.1.2-py3.4.egg/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/_vendor/distlib/compat.py",
 line 66, in 
  ImportError: cannot import name 'HTTPSHandler'
  
  ...Installing setuptools, pip, wheel...done.
  Traceback (most recent call last):
File 
"/gnu/store/h38982xp00s1g95nzr6lws31w8q8njb3-python-virtualenv-13.1.2/bin/.virtualenv-real",
 line 9, in 
  load_entry_point('virtualenv==13.1.2', 'console_scripts', 'virtualenv')()
File 
"/gnu/store/h38982xp00s1g95nzr6lws31w8q8njb3-python-virtualenv-13.1.2/lib/python3.4/site-packages/virtualenv-13.1.2-py3.4.egg/virtualenv.py",
 line 832, in main
  symlink=options.symlink)
File 
"/gnu/store/h38982xp00s1g95nzr6lws31w8q8njb3-python-virtualenv-13.1.2/lib/python3.4/site-packages/virtualenv-13.1.2-py3.4.egg/virtualenv.py",
 line 1004, in create_environment
  install_wheel(to_install, py_executable, search_dirs)
File 
"/gnu/store/h38982xp00s1g95nzr6lws31w8q8njb3-python-virtualenv-13.1.2/lib/python3.4/site-packages/virtualenv-13.1.2-py3.4.egg/virtualenv.py",
 line 969, in install_wheel
  'PIP_NO_INDEX': '1'
File 
"/gnu/store/h38982xp00s1g95nzr6lws31w8q8njb3-python-virtualenv-13.1.2/lib/python3.4/site-packages/virtualenv-13.1.2-py3.4.egg/virtualenv.py",
 line 910, in call_subprocess
  % (cmd_desc, proc.returncode))
  OSError: Command /tmp/try-virtualenv/bin/python -c "import sys, pip; 
sys...d\"] + sys.argv[1:]))" setuptools pip wheel failed with error code 1

I'm not really sure this is a problem with the new grafts system.  It
might just be that a "fix" which tears parts of a library is going to
cause unexpected problems in some places for ABI incompatibility
reasons.

Not sure if we should just wait for the world-rebuild or what right
now...!

bug#23256: vlc not building after update to ffmpeg 3.0

[Christopher Allan Webber]

vlc is failing to build after the update recently to ffmpeg 3.0.  I
verified that it builds prior to this change.

Should we include an older version of ffmpeg to build vlc with for now?
Or should we try to figure out what to do to to get vlc to build with
ffmpeg 3.0?  Maybe for now we should do the former for the aim of the latter.

Here's the output while attempting to build.

  CC   codec/libvorbis_plugin_la-vorbis.lo
  CC   codec/avcodec/libavcodec_plugin_la-video.lo
codec/avcodec/video.c: In function ‘InitVideoDec’:
codec/avcodec/video.c:226:5: error: implicit declaration of function 
‘avcodec_alloc_frame’ [-Werror=implicit-function-declaration]
 p_sys->p_ff_pic = avcodec_alloc_frame();
 ^
codec/avcodec/video.c:226:21: warning: assignment makes pointer from integer 
without a cast
 p_sys->p_ff_pic = avcodec_alloc_frame();
 ^
codec/avcodec/video.c:308:34: warning: assignment from incompatible pointer type
 p_sys->p_context->get_format = ffmpeg_GetFormat;
  ^
codec/avcodec/video.c:438:9: error: implicit declaration of function 
‘avcodec_free_frame’ [-Werror=implicit-function-declaration]
 avcodec_free_frame( _sys->p_ff_pic );
 ^
codec/avcodec/video.c: In function ‘lavc_dr_GetFrame’:
codec/avcodec/video.c:996:25: error: ‘PIX_FMT_PAL8’ undeclared (first use in 
this function)
 if (ctx->pix_fmt == PIX_FMT_PAL8)
 ^
codec/avcodec/video.c:996:25: note: each undeclared identifier is reported only 
once for each function it appears in
codec/avcodec/video.c: At top level:
codec/avcodec/video.c:1305:25: error: return type is an incomplete type
 static enum PixelFormat ffmpeg_GetFormat( AVCodecContext *p_context,
 ^
codec/avcodec/video.c:1305:25: error: conflicting types for ‘ffmpeg_GetFormat’
codec/avcodec/video.c:111:25: note: previous declaration of ‘ffmpeg_GetFormat’ 
was here
 static enum PixelFormat ffmpeg_GetFormat( AVCodecContext *,
 ^
codec/avcodec/video.c: In function ‘ffmpeg_GetFormat’:
codec/avcodec/video.c:1317:5: error: invalid use of undefined type ‘enum 
PixelFormat’
 for( size_t i = 0; pi_fmt[i] != PIX_FMT_NONE; i++ )
 ^
codec/avcodec/video.c:1317:30: error: dereferencing pointer to incomplete type
 for( size_t i = 0; pi_fmt[i] != PIX_FMT_NONE; i++ )
  ^
codec/avcodec/video.c:1317:37: error: ‘PIX_FMT_NONE’ undeclared (first use in 
this function)
 for( size_t i = 0; pi_fmt[i] != PIX_FMT_NONE; i++ )
 ^
codec/avcodec/video.c:1319:9: error: invalid use of undefined type ‘enum 
PixelFormat’
 const AVPixFmtDescriptor *dsc = av_pix_fmt_desc_get(pi_fmt[i]);
 ^
codec/avcodec/video.c:1319:67: error: dereferencing pointer to incomplete type
 const AVPixFmtDescriptor *dsc = av_pix_fmt_desc_get(pi_fmt[i]);
   ^
codec/avcodec/video.c:1324:9: error: invalid use of undefined type ‘enum 
PixelFormat’
 msg_Dbg( p_dec, "available %sware decoder output format %d (%s)",
 ^
In file included from ../include/vlc_common.h:908:0,
 from codec/avcodec/video.c:32:
codec/avcodec/video.c:1325:51: error: dereferencing pointer to incomplete type
  hwaccel ? "hard" : "soft", pi_fmt[i], dsc->name );
   ^
../include/vlc_messages.h:78:63: note: in definition of macro ‘msg_Dbg’
 vlc_Log( VLC_OBJECT(p_this), VLC_MSG_DBG,  MODULE_STRING, __VA_ARGS__ )
   ^
codec/avcodec/video.c:1344:5: error: invalid use of undefined type ‘enum 
PixelFormat’
 for( size_t i = 0; pi_fmt[i] != PIX_FMT_NONE; i++ )
 ^
codec/avcodec/video.c:1344:30: error: dereferencing pointer to incomplete type
 for( size_t i = 0; pi_fmt[i] != PIX_FMT_NONE; i++ )
  ^
codec/avcodec/video.c:1346:9: error: invalid use of undefined type ‘enum 
PixelFormat’
 if( p_va->pix_fmt != pi_fmt[i] )
 ^
codec/avcodec/video.c:1346:36: error: dereferencing pointer to incomplete type
 if( p_va->pix_fmt != pi_fmt[i] )
^
codec/avcodec/video.c:1370:9: error: invalid use of undefined type ‘enum 
PixelFormat’
 return pi_fmt[i];
 ^
codec/avcodec/video.c:1370:22: error: dereferencing pointer to incomplete type
 return pi_fmt[i];
  ^
codec/avcodec/video.c:1370:9: warning: ‘return’ with a value, in function 
returning void
 return pi_fmt[i];
 ^
codec/avcodec/video.c:1378:51: warning: passing argument 2 of 
‘avcodec_default_get_format’ from incompatible pointer type
 return avcodec_default_get_format( p_context, pi_fmt );
   ^
In file included from codec/avcodec/video.c:38:0:

bug#23256: vlc not building after update to ffmpeg 3.0

[Christopher Allan Webber]

Christopher Allan Webber writes:

> vlc is failing to build after the update recently to ffmpeg 3.0.  I
> verified that it builds prior to this change.
>
> Should we include an older version of ffmpeg to build vlc with for now?
> Or should we try to figure out what to do to to get vlc to build with
> ffmpeg 3.0?  Maybe for now we should do the former for the aim of the latter.

It looks like this is not unique to us:
  https://trac.macports.org/ticket/50697

bug#23103: A number of corrupt packages on Hydra?

[Christopher Allan Webber]

For at least boost and hydra I'm getting errors like the following:

  From http://hydra.gnunet.org/nar/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0
  Downloading jaf2s3...-ruby-2.3.0 (41.9MiB installed)...
   http://hydra.gnunet.org/nar/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0 
2.0MiB/s 00:02 | 3.4MiB transferredd
  bzip2: Compressed file ends unexpectedly;
perhaps it is corrupted?  *Possible* reason follows.
  bzip2: Inappropriate ioctl for device
Input file = (stdin), output file = (stdout)
  
  It is possible that the compressed file(s) have become corrupted.
  You can use the -tvv option to test integrity of such files.
  
  You can use the `bzip2recover' program to attempt to recover
  data from undamaged sections of corrupted files.
  
  guix substitute: error: corrupt input while restoring 
'/gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/2.3.0/rdoc/generator/template/darkfish/fonts/SourceCodePro-Regular.ttf'
 from #{read pipe}#
  killing process 8510
  guix package: error: build failed: some substitutes for the outputs of 
derivation `/gnu/store/l7ffwqbkrvd4vk3h51p597psyl44gv67-ruby-2.3.0.drv' failed 
(usually happens due to networking issues); try `--fallback' to build 
derivation from source

bug#23103: A number of corrupt packages on Hydra?

[Christopher Allan Webber]

Allegedly, Ludo has fixed this, or at least 
https://lists.gnu.org/archive/html/guix-devel/2016-03/msg01039.html
makes it sound like it :)

bug#22883: Trustable "guix pull"

[Christopher Allan Webber]

Leo Famulari writes:

> On Wed, Mar 02, 2016 at 10:03:59AM -0800, Christopher Allan Webber wrote:
>> Right now, when a user does a "guix pull", that pulls down the latest
>> repository of code from git, which is kept in a tarball.  Once you
>> receive the latest code, this has some checks: what's the hash of each
>> package, etc.
>
> A discussion worth having. But, let's merge this bug into
> debbugs.gnu.org/22629.

I'm not sure they should be merged, though they're related.  That thread
doesn't deal at all with security, though it provides some other good
ideas.  It even says:

  PS: I do not mention the issue of authenticating code here, which is
  obviously very important and deserves to be treated separately.

However I have no objections to merging them if others think we should

> Also, we should read "The Update Framework" as requested there.

This?  https://theupdateframework.github.io/

There seem to be quite a few papers there!

bug#22738: Build failure in vigra

[Christopher Allan Webber]

Andreas Enge writes:

> On Thu, Feb 18, 2016 at 10:59:11PM -0500, Leo Famulari wrote:
>> It looks like we need this module 'vigranumpy':
>> https://ukoethe.github.io/vigra/doc-release/vigranumpy/index.html
>
> This is part of the vigra source code. There should soon be a new vigra
> release:
>
> https://mailhost.informatik.uni-hamburg.de/pipermail/vigra/2016-February/001317.html
> but it also failed its tests for me (in another place).
>
> I made a bug report on the vigra mailing list:
>
> https://mailhost.informatik.uni-hamburg.de/pipermail/vigra/2016-February/001319.html
>
> Andreas

It looks like this is fixed:
  
https://mailhost.informatik.uni-hamburg.de/pipermail/vigra/2016-February/001325.html

Is it possible to get an updated version of this package in, then?

bug#22868: letsencrypt certs don't work for git repositories

[Christopher Allan Webber]

See:

$ git clone https://git.dthompson.us/presentations.git davexunit-presentations
Cloning into 'davexunit-presentations'...
fatal: unable to access 'https://git.dthompson.us/presentations.git/': server 
certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt 
CRLfile: none

bug#25205: Guix package is using the GuixSD logo instead of the Guix logo

[Christopher Allan Webber]

Ludovic Courtès writes:

> Hello Felipe!
>
> Luis Felipe López Acevedo  skribis:
>
>> Steps to reproduce
>> ==
>>
>> 1. Go to https://www.gnu.org/software/guix/packages/g.html
>> 2. Locate a guix package, and click on the "Expand" button
>>
>>
>> Unexpected behavior
>> ===
>>
>> The description shows the logotype of the Guix System Distribution.
>
> The list of GNU package logos is maintained separately, in the “GNU
> womb” project at .  So in
> general such reports should go to bug-w...@gnu.org.
>
> However, I would argue that the original Guix logotype is mostly
> superseded by the other one.  I’ve come to the conclusion that it’s
> confusion to have two logos, and that the GuixSD one is cute anyway.
> :-)
>
> WDYT?

I strongly support this.

bug#26608: Provide --only-substitutes flag to "guix package --upgrade"

[Christopher Allan Webber]

Sometimes I do an upgrade and I want to get the latest security updates,
but I also am not really available to burn through a lot of cpu time,
(especially on my x200).

I'd love it if thre were a flag so that I could specify "only bother to
upgrade the packages where we only upgrade if a substitute is already
available.

Note that I looked at the source to see if this would be an easy thing
to add; I figured that this would be handled in roughly the same place
as --keep-going or --fallback, but it looks to me like those are
actually just passed over to the build daemon, so I'm not so sure how
easy it would be to patch this in while we're still using Nix's C
daemon?  I'm not sure.

bug#26610: python-gpg broke; python-gpg 1.9.0 does not exist

[Christopher Allan Webber]

Commit 8439c9c05e upgraded gpgme to 1.9.0.

Unfortunately, python-gpg's version is tied to gpgme:

(define-public python-gpg
  (package
(name "python-gpg")
(version (package-version gpgme))
;; [...]

This is a problem, because upgrading gpgme "automatically" upgraded
python-gpg, and there is no python-gpg release of 1.9.0.  The latest
release is 1.8.0:

  https://pypi.python.org/pypi/gpg/1.8.0

I'm not sure it makes sense to tie the package version to python-gpg's
package version anyway... if upgrading gpgme does trigger the upgrade of
python-gpg "automatically", then that would mean that even if there was
a pythong-gpg available with the new version, the hash would be
incorrect.

bug#25961: Compiling new guix on old guix: 'waitpid' -1 failed unexpectedly: No child processes

[Christopher Allan Webber]

Hello!  I'm getting this error while trying to compile latest guix
master on one of my machines (fortunately, not my main one).  I don't
know why I'm hitting this error, since I'm not hitting it on my main
machine.  I'm upgrading from a few months back.

I spoke on irc and found that Ricardo had the same issue:

   paroneayea: I also got this error trying to run “make”
   paroneayea: it happens on my recording machine (x86_64) that hadn’t
   been updated in a while, but not on my laptop (also x86_64), which is
   updated regularly.

Here's what I do.  I start at the commit I was at
(c2662820f359be19262cdd5d564e6a0dddc43281) and run "guix environment
guix".  Then I do a "git pull && make clean && make" and I get:

  ;;; Failed to autoload cairo-image-surface-create in (cairo):
  ;;; ERROR: missing interface for module (cairo)
  ;;; Failed to autoload cairo-image-surface-create in (cairo):
  ;;; ERROR: missing interface for module (cairo)
  ;;; Failed to autoload rsvg-handle-new-from-file in (rsvg):
  ;;; ERROR: missing interface for module (rsvg)
  ;;; Failed to autoload cairo-image-surface-create in (cairo):
  ;;; ERROR: missing interface for module (cairo)
  ;;; Failed to autoload rsvg-handle-new-from-file in (rsvg):
  ;;; ERROR: missing interface for module (rsvg)
  ;;; Failed to autoload cairo-image-surface-create in (cairo):
  ;;; ERROR: missing interface for module (cairo)
LOAD (gnu build vm)
LOAD (gnu tests)
LOAD (gnu tests base)
LOAD (gnu tests nfs)
LOAD (gnu tests install)
  warning: 'waitpid' -1 failed unexpectedly: No child processes
  Backtrace:
  In ice-9/boot-9.scm:
  3088: 19 [#]
  In unknown file:
 ?: 18 [primitive-load-path "gnu/tests/install" ...]
  In ice-9/eval.scm:
   453: 17 [eval # ()]
   411: 16 [eval # #]
   387: 15 [eval # #]
   373: 14 [run-install # #]
   387: 13 [eval # #]
   387: 12 [eval # #]
   387: 11 [eval # #]
   411: 10 [eval # #]
  In srfi/srfi-1.scm:
   573: 9 [map # (# # # # ...)]
  In ice-9/eval.scm:
   387: 8 [eval # #]
   411: 7 [eval # #]
   411: 6 [eval # #]
   387: 5 [eval # #]
  In unknown file:
 ?: 4 [force #>]
  In ice-9/eval.scm:
   411: 3 [eval # #]
   411: 2 [eval # #]
  In ice-9/popen.scm:
98: 1 [close-process # 28701]
  In unknown file:
 ?: 0 [waitpid 28701 #]

  ERROR: In procedure waitpid:
  ERROR: In procedure waitpid: No child processes
  make[2]: *** [Makefile:4929: make-go] Error 1
  make[2]: Leaving directory '/home/cwebber/src/guix'
  make[1]: *** [Makefile:4072: all-recursive] Error 1
  make[1]: Leaving directory '/home/cwebber/src/guix'
  make: *** [Makefile:2728: all] Error 2

This is on commit 21abf092a49f0ce80cbfff5cccabb7dbf53abf96

If instead I switch back to c2662820f359be19262cdd5d564e6a0dddc43281 I
can compile Guix again.

I did a git-bisect to find what commit was breaking things.  According
to git-bisect, the perpetrator is:

  63302a4e55241a41eab4c21d7af9fbd0d5817459 is the first bad commit
  commit 63302a4e55241a41eab4c21d7af9fbd0d5817459
  Author: Ludovic Courtès 
  Date:   Mon Feb 6 23:47:09 2017 +0100

  Add (gnu build shepherd).

  * gnu/build/shepherd.scm: New file.
  * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.

  :04 04 7a07b30ebec719aca2fba4c2776f7152e669a1ee 
63eb6bc3fa184fc42c3d469d594fc056f16b7892 Mgnu
  bisect run success

I've confirmed this by double-checking that I can build the commit
before but not this commit.

I don't really know why this fails, but it looks like it's somehow
triggering a remote process in some way related to tests and
shepherd... which is confusing, because I don't think this happening
during tests.

 - Chris

bug#25961: Compiling new guix on old guix: 'waitpid' -1 failed unexpectedly: No child processes

[Christopher Allan Webber]

Marius Bakke  writes:

> Which kernel version is this?

Linux-Libre 4.8.1

And!  As it turns out, I went to the last revision before I was hitting
compilation isues (c90db25f4cf1f98f3f4f3af38d175a14ffb8c32a), did a make
on the repo, and from there I did a "guix system reconfigure".  I
restarted, and after that I was able to build the repo on git master. 
If it's because of the kernel that things work now, it did upgrade the
kernel... the kernel is now at 4.9.8.

I wonder why this happened?

bug#27795: Issues with upstream source for guile-emacs

[Christopher Allan Webber]

Leo Famulari writes:

> On Sun, Jul 23, 2017 at 04:22:06PM +0200, Ricardo Wurmus wrote:
>>
>> Ricardo Wurmus  writes:
>>
>> > Leo Famulari  writes:
>> >
>> >> While working on the bug 'Changing package source URLs from git:// to
>> >> https://' [0], I noticed an issue with the sources for guile-emacs.
>> >>
>> >> We currently fetch this source code over the unauthenticated GIT
>> >> protocol. It is also available over HTTPS. However, these two protocols
>> >> are returning different Git repos for some reason.
>> >
>> > The clone times out for me:
>> >
>> > --8<---cut here---start->8---
>> > git clone https://git.hcoop.net/git/bpt/emacs.git guile-emacs-over-https
>> > Cloning into 'guile-emacs-over-https'...
>> > ^C
>> > --8<---cut here---end--->8---
>> >
>> > But the clone from git:// works fine.
>> >
>> > Is the repository actually served over HTTPS?
>>
>> Don’t mind me.  It eventually worked.  The repositories have different
>> histories, and the https-repo looks like it is two commits behind.
>> Looks like an older rebase.
>>
>> I’d say we should leave it with the current git:// URL.
>
> The thing is, since the git:// protocol is unauthenticated, we could
> assume that those extra two commits are added by a MitM :/
>
> Somebody who is interested in guile-emacs should really ask upstream
> what is going on.

Since we hash the checkout's contents, an attacker would have to be very
consistently adding those two commits for both the original packager
(me) and all subsequent users... a possible attack, but I think it's not
the biggest thing to worry about.

bug#26695: openssh password-authentication? should be #f by default

[Christopher Allan Webber]

Marius Bakke writes:

>> We have discussed in the past having some service that just copies some
>> static files on init.  That would be enough to set up public keys
>> appropriately.
>
> I think that can already be done with 'special-file-service-type'.
>
> https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00332.html

Interesting!  I'll have to try this route.

bug#26695: openssh password-authentication? should be #f by default

[Christopher Allan Webber]

Maxim Cournoyer writes:

> +1. Although it means the keys will have to be copied by another mean
> than the "ssh-copy-id" script. Maybe the configuration could accept
> the public key? :) I haven't checked if this is already possible.

We have discussed in the past having some service that just copies some
static files on init.  That would be enough to set up public keys
appropriately.

That's a different, but related bug :)

bug#26695: openssh password-authentication? should be #f by default

[Christopher Allan Webber]

Our default permits password authentication for the openssh service (and
the others it seems) by default in Guix.  This is somewhat dangerous
because this is a much easier to break in this way, and some users might
not assume the default is reasonably safe.  If users really want
password-authentication, they should turn it on explicitly.

bug#26696: openssh: root 'without-password & password-authentication #f both breaks service

[Christopher Allan Webber]

I wanted to permit root logins but only permit public key authentication
in my openssh configuration.  This was my original assumption of how to
do it:

  (service openssh-service-type
  (openssh-configuration
   (permit-root-login 'without-password)
   (password-authentication? #f)))

However, for whatever reason, openssh fails to start with this
combination.  However, it turns out this is redundant, since the
configuration is already only permitting with public key authentication.

  (service openssh-service-type
  (openssh-configuration
   (permit-root-login #t)
   (password-authentication? #f)))

This route is sufficient.

However maybe we should prevent people from accidentally causing openssh
to not start.  Here's a suggested route... though I haven't tested it:

#+BEGIN_SRC diff
diff --git a/gnu/services/ssh.scm b/gnu/services/ssh.scm
index 9917c311c..f1f2ab3dc 100644
--- a/gnu/services/ssh.scm
+++ b/gnu/services/ssh.scm
@@ -342,7 +342,13 @@ The other options should be self-descriptive."
#$(match (openssh-configuration-permit-root-login config)
(#t "yes")
(#f "no")
-   ('without-password "without-password")))
+   ('without-password
+;; If we've already disabled password-authentication, 
this
+;; is redundant, and even stops the openssh server from
+;; starting up
+(if (openssh-configuration-password-authentication? 
config)
+"without-password"
+"yes"
(format port "PermitEmptyPasswords ~a\n"
#$(if (openssh-configuration-allow-empty-passwords? config)
  "yes" "no"))
#+END_SRC

bug#28193: tome4 tiles are nonfree?

[Christopher Allan Webber]

I was excited to see tome4 packaged for Guix since that game is
*incredible*.  However, I'm not totally sure about the music, but as for
the tiles, there's this message in tome4's COPYING-MEDIA which says:

  All the medias located in all the "/data/gfx" folders are granted to
  use with the Tales of Maj'Eyal game only.

  Please contact dark...@te4.org for more informations.

It seems to me that we will have to strip these out.  It's a shame,
because it's a really beautiful tileset which adds a lot of atmosphere.
I think the game is still playable in ascii mode, though I haven't tried
doing it.

Sorry to be a downer...

bug#26917: [PATCH] Add thermald and thermald-service-type (for cpu frequency scaling)

[Christopher Allan Webber]

Bah, this should have been sent to guix-patches.

Christopher Allan Webber writes:

> Hello!  I got tired of my laptop crashing so much due to overheating, so
> here's a package for thermald as well as a service type.
>
>>From 56c7019d58d4a064fe44e626a1396b62cbf808b0 Mon Sep 17 00:00:00 2001
> From: Christopher Allan Webber <cweb...@dustycloud.org>
> Date: Sat, 13 May 2017 19:36:01 -0500
> Subject: [PATCH 1/2] gnu: Add thermald.
>
> * gnu/packages/admin.scm (thermald): New variable.
> ---
>  gnu/packages/admin.scm | 54 
> +-
>  1 file changed, 53 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
> index ff0431999..20cb8f180 100644
> --- a/gnu/packages/admin.scm
> +++ b/gnu/packages/admin.scm
> @@ -17,6 +17,7 @@
>  ;;; Copyright © 2016 John Darrington <j...@gnu.org>
>  ;;; Copyright © 2017 Ben Sturmfels <b...@sturm.com.au>
>  ;;; Copyright © 2017 Ethan R. Jones <doubleplusgoo...@gmail.com>
> +;;; Copyright © 2017 Christopher Allan Webber <cweb...@dustycloud.org>
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -80,7 +81,8 @@
>#:use-module (gnu packages autotools)
>#:use-module (gnu packages gnome)
>#:use-module (gnu packages kerberos)
> -  #:use-module (gnu packages gtk))
> +  #:use-module (gnu packages gtk)
> +  #:use-module (gnu packages xml))
>  
>  (define-public aide
>(package
> @@ -2130,3 +2132,53 @@ logo, or any ASCII file of your choice.  The main 
> purpose of Neofetch is to be
>  used in screenshots to show other users what operating system or distribution
>  you are running, what theme or icon set you are using, etc.")
>  (license license:expat)))
> +
> +(define-public thermald
> +  (package
> +(name "thermald")
> +(version "1.6")
> +(source
> + (origin
> +  (method url-fetch)
> +  (uri (string-append "https://github.com/01org/thermal_daemon/archive/v;
> +  version ".tar.gz"))
> +  (sha256 (base32
> +   "14klz9fnvi9jdlaqwrp61xa5nh051n8ykrs1fh1wxd7j66qf2fn6"
> +(build-system gnu-build-system)
> +(arguments
> + `(#:phases (modify-phases %standard-phases
> +  (add-after
> +   'unpack 'autogen.sh-and-fix-paths
> +   (lambda* (#:key outputs #:allow-other-keys)
> + (let ((out (assoc-ref outputs "out")))
> +   ;; upstartconfir is hardcoded to /etc/init and the 
> build
> +   ;; system tries to mkdir that.  We don't even need 
> upstart
> +   ;; files at all; this is a fast and kludgy workaround
> +   (substitute* "data/Makefile.am"
> + (("upstartconfdir = /etc/init")
> +  (string-append "upstartconfdir = "
> + out "/etc/init")))
> +   ;; Now run autogen
> +   (zero? (system* "sh" "autogen.sh"))
> +   #:configure-flags
> +   (let ((out  (assoc-ref %outputs "out")))
> + (list (string-append "--sysconfdir="
> +  out "/etc")
> +   (string-append "--with-udev-dir="
> +  out "/lib/udev")
> +   (string-append "--with-dbus-sys-dir="
> +  out "/etc/dbus-1/system.d")
> +   "--localstatedir=/var"
> +(native-inputs
> + `(("autoconf" ,autoconf)
> +   ("automake" ,automake)
> +   ("glib" ,glib "bin")     ; for glib-genmarshal, etc.
> +   ("pkg-config" ,pkg-config)))
> +(inputs
> + `(("dbus-glib" ,dbus-glib)
> +   ("libxml2" ,libxml2)))
> +(home-page "https://01.org/linux-thermal-daemon/;)
> +(synopsis "CPU scaling for thermal management")
> +(description "The Linux Thermal Daemon helps monitor and control 
> temperature
> +on systems running the Linux kernel.")
> +(license license:gpl2+)))
> -- 
> 2.12.2
>
>>From de2045cdc81ddef7b01b3445fb731a3252f5b4a8 Mon Sep 17 00:00:00 2001
> From: Christopher Allan Webber <cweb...@dustycloud.org>
> Date: Sat, 13 May 2017 19:37:02 -0500
> Subject: [PATCH 2/2] services: Add 'thermald-service-type'.
>
> * gnu/services/admin.scm (): New record type.
> (thermald-shepherd-

bug#26917: [PATCH] Add thermald and thermald-service-type (for cpu frequency scaling)

[Christopher Allan Webber]

Hello!  I got tired of my laptop crashing so much due to overheating, so
here's a package for thermald as well as a service type.

>From 56c7019d58d4a064fe44e626a1396b62cbf808b0 Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber <cweb...@dustycloud.org>
Date: Sat, 13 May 2017 19:36:01 -0500
Subject: [PATCH 1/2] gnu: Add thermald.

* gnu/packages/admin.scm (thermald): New variable.
---
 gnu/packages/admin.scm | 54 +-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index ff0431999..20cb8f180 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -17,6 +17,7 @@
 ;;; Copyright © 2016 John Darrington <j...@gnu.org>
 ;;; Copyright © 2017 Ben Sturmfels <b...@sturm.com.au>
 ;;; Copyright © 2017 Ethan R. Jones <doubleplusgoo...@gmail.com>
+;;; Copyright © 2017 Christopher Allan Webber <cweb...@dustycloud.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -80,7 +81,8 @@
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages gnome)
   #:use-module (gnu packages kerberos)
-  #:use-module (gnu packages gtk))
+  #:use-module (gnu packages gtk)
+  #:use-module (gnu packages xml))
 
 (define-public aide
   (package
@@ -2130,3 +2132,53 @@ logo, or any ASCII file of your choice.  The main purpose of Neofetch is to be
 used in screenshots to show other users what operating system or distribution
 you are running, what theme or icon set you are using, etc.")
 (license license:expat)))
+
+(define-public thermald
+  (package
+(name "thermald")
+(version "1.6")
+(source
+ (origin
+  (method url-fetch)
+  (uri (string-append "https://github.com/01org/thermal_daemon/archive/v;
+  version ".tar.gz"))
+  (sha256 (base32
+   "14klz9fnvi9jdlaqwrp61xa5nh051n8ykrs1fh1wxd7j66qf2fn6"
+(build-system gnu-build-system)
+(arguments
+ `(#:phases (modify-phases %standard-phases
+  (add-after
+   'unpack 'autogen.sh-and-fix-paths
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+   ;; upstartconfir is hardcoded to /etc/init and the build
+   ;; system tries to mkdir that.  We don't even need upstart
+   ;; files at all; this is a fast and kludgy workaround
+   (substitute* "data/Makefile.am"
+ (("upstartconfdir = /etc/init")
+  (string-append "upstartconfdir = "
+ out "/etc/init")))
+   ;; Now run autogen
+   (zero? (system* "sh" "autogen.sh"))
+   #:configure-flags
+   (let ((out  (assoc-ref %outputs "out")))
+ (list (string-append "--sysconfdir="
+  out "/etc")
+   (string-append "--with-udev-dir="
+  out "/lib/udev")
+   (string-append "--with-dbus-sys-dir="
+  out "/etc/dbus-1/system.d")
+   "--localstatedir=/var"
+(native-inputs
+ `(("autoconf" ,autoconf)
+   ("automake" ,automake)
+   ("glib" ,glib "bin") ; for glib-genmarshal, etc.
+   ("pkg-config" ,pkg-config)))
+(inputs
+ `(("dbus-glib" ,dbus-glib)
+   ("libxml2" ,libxml2)))
+(home-page "https://01.org/linux-thermal-daemon/;)
+(synopsis "CPU scaling for thermal management")
+(description "The Linux Thermal Daemon helps monitor and control temperature
+on systems running the Linux kernel.")
+(license license:gpl2+)))
-- 
2.12.2

>From de2045cdc81ddef7b01b3445fb731a3252f5b4a8 Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber <cweb...@dustycloud.org>
Date: Sat, 13 May 2017 19:37:02 -0500
Subject: [PATCH 2/2] services: Add 'thermald-service-type'.

* gnu/services/admin.scm (): New record type.
(thermald-shepherd-service, thermald-service-type): New variables.
* doc/guix.texi (Thermal Management): New section documenting thermald.
---
 doc/guix.texi  | 23 ++-
 gnu/services/admin.scm | 51 ++
 2 files changed, 69 insertions(+), 5 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 22dc8b3f9..1fee7616c 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -35,7 +35,8 @@ Copyright @copyright{} 2017 Mathieu Othacehe@*
 Copyright @copyright{} 2017 Federico Beffa@*
 Copyright @copyright{} 2017 Carlo Zancanaro@*
 Copyright @copyrigh

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

[Christopher Allan Webber]

Clément Lassieur writes:

> Clément Lassieur  writes:
>
>>> I just flashed the latest stable of libreboot and for t400 it is fixed,
>>> I can recover from suspend. Thanks to the amazing work of Leah and all
>>> other libreboot contributors :)
>>
>> I still reproduce the bug with latest stable and x200.
>
> This is probably a libreboot bug, because it is reproducible with
> Debian.  Closing it.

Libreboot is probably involved, but it's a combination of libreboot +
linux-libre upgrades fwiw.

I'm running an X200 with an older version of Libreboot.  I just verified
that Linux 4.10.X still suspends fine, but 4.11 fails to suspend.

Anyway, not saying it shouldn't be closed, but maybe useful information
for people to have.

bug#28193: tome4 tiles are nonfree?

[Christopher Allan Webber]

Christopher Allan Webber writes:

>> Thanks for bringing this to our attention.  The GNU FSDG requirements
>> for non-functional data are relatively permissive:
>>
>>   Non-functional Data
>>   
>>   Data that isn't functional, that doesn't do a practical job, is more
>>   of an adornment to the system's software than a part of it.  Thus, we
>>   don't insist on the free license criteria for non-functional data.  It
>>   can be included in a free system distribution as long as its license
>>   gives you permission to copy and redistribute, both for commercial and
>>   non-commercial purposes.  For example, some game engines released
>>   under the GNU GPL have accompanying game information—a fictional world
>>   map, game graphics, and so on—released under such a
>>   verbatim-distribution license.  This kind of data can be part of a
>>   free system distribution, even though its license does not qualify as
>>   free, because it is non-functional.
>>
>>   
>> https://www.gnu.org/distros/free-system-distribution-guidelines.html#non-functional-data
>
> Oh, I didn't realize that.
>
>> I cannot tell from the text above whether restricting the use of game
>> graphics to a particular game is permitted by the GNU FSDG.  I think we
>> should ask for clarification from the gnu-linux-li...@nongnu.org mailing
>> list.  Would you be willing to ask?
>>
>>   Mark
>
> Sure, I can ask.

I haven't heard anything back.  I'm assuming it's probably fine, given
the FSDG quoted above.  Closing!

bug#28578: xorg not starting on x200 due to recent commit

[Christopher Allan Webber]

Chris Marusich writes:

> Christopher Allan Webber <cweb...@dustycloud.org> writes:
>
>> The following commit to guix makes it so that I can't start xorg:
>>
>>   c68c201fdd429140da1c606861c9296b9cb01265
>>   Author: Andy Wingo <wi...@igalia.com>
>>   CommitDate: Wed Sep 20 15:40:31 2017 +0200
>>   
>>   gnu: xorg-server: Prefer intel driver only for older GPUs.
>>   
>>   * gnu/packages/xorg.scm (xorg-server): Add patch to only prefer the intel
>> driver for older Intel GPUs.
>>
>> The commit seems useful, but unfortunately I think I'm not the only x200
>> user, and this is breaking things for me!  I wonder if there's a way to
>> keep the commit's purpose/feature without breaking xorg on x200s?
>
> For what it's worth, I use an X200, I did a guix pull followed by a
> system reconfigure just yesterday, and it boots fine for me.  I wonder
> what is different about my setup compared to yours?

Not sure.  Are you running libreboot?

bug#28578: xorg not starting on x200 due to recent commit

[Christopher Allan Webber]

The following commit to guix makes it so that I can't start xorg:

  c68c201fdd429140da1c606861c9296b9cb01265
  Author: Andy Wingo 
  CommitDate: Wed Sep 20 15:40:31 2017 +0200
  
  gnu: xorg-server: Prefer intel driver only for older GPUs.
  
  * gnu/packages/xorg.scm (xorg-server): Add patch to only prefer the intel
driver for older Intel GPUs.

The commit seems useful, but unfortunately I think I'm not the only x200
user, and this is breaking things for me!  I wonder if there's a way to
keep the commit's purpose/feature without breaking xorg on x200s?

bug#28578: xorg not starting on x200 due to recent commit

[Christopher Allan Webber]

Chris Marusich writes:

> Leo Famulari <l...@famulari.name> writes:
>
>> On Sun, Sep 24, 2017 at 05:15:02PM -0700, Chris Marusich wrote:
>>> Christopher Allan Webber <cweb...@dustycloud.org> writes:
>>> 
>>> > The following commit to guix makes it so that I can't start xorg:
>>> >
>>> >   c68c201fdd429140da1c606861c9296b9cb01265
>>> >   Author: Andy Wingo <wi...@igalia.com>
>>> >   CommitDate: Wed Sep 20 15:40:31 2017 +0200
>>> >   
>>> >   gnu: xorg-server: Prefer intel driver only for older GPUs.
>>> >   
>>> >   * gnu/packages/xorg.scm (xorg-server): Add patch to only prefer the 
>>> > intel
>>> > driver for older Intel GPUs.
>>> >
>>> > The commit seems useful, but unfortunately I think I'm not the only x200
>>> > user, and this is breaking things for me!  I wonder if there's a way to
>>> > keep the commit's purpose/feature without breaking xorg on x200s?
>>> 
>>> For what it's worth, I use an X200, I did a guix pull followed by a
>>> system reconfigure just yesterday, and it boots fine for me.  I wonder
>>> what is different about my setup compared to yours?
>>
>> I don't know if it's relevant, but note that the X200 and X200s are
>> different models.
>
> It might be relevant.  I thought Chris was using the word "x200s" as in
> "two or more x200 computers", but perhaps he meant the model "x200s".  I
> do not have an x200s; I have an x200.
>
> Also, yes, I use Libreboot, but I am not sure why that would matter for
> something like xorg, which comes into action late in the boot process,
> long after Libreboot hands off control to the operating system.

I run an x200 as well.  In case it is useful, here is the output of
lspci cut down to video-relevant stuff.

00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory 
Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 07)

bug#28193: tome4 tiles are nonfree?

[Christopher Allan Webber]

Mark H Weaver writes:

> Hi Chris,
>
> Christopher Allan Webber <cweb...@dustycloud.org> writes:
>
>> I was excited to see tome4 packaged for Guix since that game is
>> *incredible*.  However, I'm not totally sure about the music, but as for
>> the tiles, there's this message in tome4's COPYING-MEDIA which says:
>>
>>   All the medias located in all the "/data/gfx" folders are granted to
>>   use with the Tales of Maj'Eyal game only.
>>
>>   Please contact dark...@te4.org for more informations.
>>
>> It seems to me that we will have to strip these out.
>
> Thanks for bringing this to our attention.  The GNU FSDG requirements
> for non-functional data are relatively permissive:
>
>   Non-functional Data
>   
>   Data that isn't functional, that doesn't do a practical job, is more
>   of an adornment to the system's software than a part of it.  Thus, we
>   don't insist on the free license criteria for non-functional data.  It
>   can be included in a free system distribution as long as its license
>   gives you permission to copy and redistribute, both for commercial and
>   non-commercial purposes.  For example, some game engines released
>   under the GNU GPL have accompanying game information—a fictional world
>   map, game graphics, and so on—released under such a
>   verbatim-distribution license.  This kind of data can be part of a
>   free system distribution, even though its license does not qualify as
>   free, because it is non-functional.
>
>   
> https://www.gnu.org/distros/free-system-distribution-guidelines.html#non-functional-data

Oh, I didn't realize that.

> I cannot tell from the text above whether restricting the use of game
> graphics to a particular game is permitted by the GNU FSDG.  I think we
> should ask for clarification from the gnu-linux-li...@nongnu.org mailing
> list.  Would you be willing to ask?
>
>   Mark

Sure, I can ask.