bug#22548: Kernel panic after system reconfiguration

[Alex Kost]

Mark H Weaver (2016-02-04 01:14 +0300) wrote:

> Albin  writes:
>
>> Hi again,
>>
>> I got rid of the kernel panic by removing the following from the config
>> and reconfiguring (as suggested by Mark Weaver):
>>
>>> (swap-devices '("/swapfile"))
>>
>> It would be nice to be able to enable swap again though. On my system it
>> needs to be done with a swap file.
>
> I suspect this never worked, but that before the error was silently
> ignored.  In my case, I had:
>
>   (swap-devices '("/dev/disk/by-label/jojen-swap"))
>
> and /dev/disk went away at some point due to another problem.  For a
> long time, I simply had no swap.  With the dmd -> shepherd transition,
> it started causing a fatal error during boot, leading to a kernel panic.
> Unfortunately, the error message scrolled off the screen very quickly,
> obscured by a useless kernel backtrace.

I faced the same kernel panic as I also had "/dev/disk/..." swap device.

Obviously it didn't work for some time when dmd was the init system
(because on GuixSD there is no "/dev/disk/" since… I don't know when as
I've never noticed it before).

And as reported by several people on #guix (I count at least 4 including
me and Mark) a wrong swap device leads to a kernel panic if shepherd is
used as the init system.

Until I realized that it was a wrong swap, I made bisecting on shepherd
to find out which commit introduced this bug.  It gave me commit
852341e¹: when I reconfigured my system (with a wrong swap) using
shepherd on this commit, I had a kernel panic, while with shepherd on
the previous commit the system booted successfully.

¹ 
http://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=852341ed0c08941cbdd022135f8bef7be2d7ec54

-- 
Alex

bug#22548: Kernel panic after system reconfiguration

[Ludovic Courtès]

Alex Kost  skribis:

> And as reported by several people on #guix (I count at least 4 including
> me and Mark) a wrong swap device leads to a kernel panic if shepherd is
> used as the init system.
>
> Until I realized that it was a wrong swap, I made bisecting on shepherd
> to find out which commit introduced this bug.  It gave me commit
> 852341e¹: when I reconfigured my system (with a wrong swap) using
> shepherd on this commit, I had a kernel panic, while with shepherd on
> the previous commit the system booted successfully.
>
> ¹ 
> http://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=852341ed0c08941cbdd022135f8bef7be2d7ec54

Ooooh, it took me a while but I see how this happens.  This is because
we start services directly from the config file, and anything that goes
wrong there is uncaught, which leads to this:

--8<---cut here---start->8---
Service udev has been started.
srfi-34(# 184b150> 
action: start key: system-error arguments: ("swapon" "~S: ~A" 
("/dev/disk/foobar" "No such file or directory") (2))] 1ea24c0>)
[6.856167] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0100
[6.856167] 
[6.856869] CPU: 0 PID: 1 Comm: shepherd Not tainted 4.4.1-gnu #1
[6.857319] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
--8<---cut here---end--->8---

Ludo’.

bug#22533: Non-determinism in python-3 ".pyc" bytecode

[Leo Famulari]

On Tue, Feb 02, 2016 at 09:41:19PM +0100, Ludovic Courtès wrote:
> Could you give it a try and refine as needed?  :-)

I altered your example as shown in the attached patch. It causes some
tests related to timestamps to fail, so I disabled them in a very crude
way. The final patch should address those tests more carefully.

But, the patch doesn't seem to have the desired effect so I'm asking for
help!

Here is how I tested the patch:

I build python-3 with it, and then `export SOURCE_DATE_EPOCH=1` and
enter the resulting Python shell. I manually define the '_w_long'
function used by the patched function. Then: 

print (_w_long(locale.atoi(os.getenv('SOURCE_DATE_EPOCH'
b'\x01\x00\x00\x00'

But, when I leave the Python shell and issue `python3 -m compileall
helloworld.py`, the timestamps are present in the compiled bytecode. I
can watch the clock "tick" by doing this repeatedly:

$ touch helloworld.py && rm -r __pycache__ && \
python3 -m compileall helloworld.py &&  \
hexdump __pycache__/helloworld.cpython-34.pyc | head -n1

I'm not much of a Python programmer, so I'm stumped.
>From d34a71e4ec4501cb53acd3e15633bc1a05665be9 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Leo Famulari 
Date: Wed, 3 Feb 2016 20:44:02 -0500
Subject: [PATCH 1/1] SOURCE_DATE_EPOCH

---
 .../patches/python-3.4.3-source-date-epoch.patch| 21 +
 gnu/packages/python.scm | 14 +-
 2 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/python-3.4.3-source-date-epoch.patch

diff --git a/gnu/packages/patches/python-3.4.3-source-date-epoch.patch b/gnu/packages/patches/python-3.4.3-source-date-epoch.patch
new file mode 100644
index 000..403b2df
--- /dev/null
+++ b/gnu/packages/patches/python-3.4.3-source-date-epoch.patch
@@ -0,0 +1,21 @@
+diff --git a/Lib/importlib/_bootstrap.py b/Lib/importlib/_bootstrap.py
+index 5b91c05..a87d178 100644
+--- Lib/importlib/_bootstrap.py
 Lib/importlib/_bootstrap.py
+@@ -666,8 +666,15 @@ def _compile_bytecode(data, name=None, bytecode_path=None, source_path=None):
+ def _code_to_bytecode(code, mtime=0, source_size=0):
+ """Compile a code object into bytecode for writing out to a byte-compiled
+ file."""
++"""os and locale are required for the SOURCE_DATE_EPOCH
++deterministic timestamp conditional."""
++import os
++import locale
+ data = bytearray(MAGIC_NUMBER)
+-data.extend(_w_long(mtime))
++if os.getenv('SOURCE_DATE_EPOCH'):
++data.extend(_w_long(locale.atoi(os.getenv('SOURCE_DATE_EPOCH'
++else:
++data.extend(_w_long(mtime))
+ data.extend(_w_long(source_size))
+ data.extend(marshal.dumps(code))
+ return data
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 48f65b5..cd366f5 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -173,6 +173,17 @@
  ;; gnu-build-system.scm.
  (setenv "SOURCE_DATE_EPOCH" "1")
  #t))
+  (add-before 'configure 'disable-timestamp-tests
+(lambda _
+  ;; Filter for existing files, since this only affects
+  ;; Python-3 if the SOURCE_DATE_EPOCH patch is applied.
+  (substitute* (filter file-exists?
+   '("Lib/test/test_importlib/test_abc.py"))
+   (("test_code_bad_timestamp") "disable_test_code_bad_timestamp"))
+  (substitute* (filter file-exists?
+   '("Lib/test/test_importlib/source/test_file_loader.py"))
+   (("test_old_timestamp") "disable_test_old_timestamp"))
+  ))
   (add-before 'configure 'do-not-record-configure-flags
 (lambda* (#:key configure-flags #:allow-other-keys)
   ;; Remove configure flags from the installed '_sysconfigdata.py'
@@ -268,7 +279,8 @@ data types.")
   ;; XXX Try removing this patch for python > 3.4.3
   "python-disable-ssl-test.patch"
   "python-3-deterministic-build-info.patch"
-  "python-3-search-paths.patch")))
+  "python-3-search-paths.patch"
+  "python-3.4.3-source-date-epoch.patch")))
   (patch-flags '("-p0"))
   (sha256
(base32
-- 
2.6.3

bug#22550: (require 'magit) produces error: "no such file or directory" "dash"

[myglc2]

Alex Kost  writes:

> myglc2 (2016-02-04 18:16 +0300) wrote:
>
>> So, should I put ...
>>
>> '(guix-emacs-load-autoloads "/run/current-system/profile")'
>>
>> ... in init.el, in which case guix INFO should say so.
>
> Well, you can do it as a temporary workaround, but we'll fix it soon (I
> mean the system profile will also be inspected for emacs packages), so
> it will not be necessary in the closest future.
>
>> Or, is there something wrong with EMACSLOADPATH?
>
> Yes, I mean it's not a problem on your side, but it's bug in GuixSD. I
> think we should change this value from ":/etc/emacs" to "/etc/emacs:".
> The problem with the current EMACSLOADPATH is that "/etc/emacs" value is
> appended to 'load-path' variable, but it should be prepended to it, so
> that the proper "site-lisp.el" will be found.
>
> Sorry, this bug was introduced recently and you are the first who faced
> it :-)

Not to worry... bugs must be made in the course of progress.

>
> Right now I can't check it, but I think if you start emacs like this:
>
>   EMACSLOADPATH=/etc/emacs: emacs
>
> you'll get "M-x guix-…" commands.  Could you confirm?

Yes that works.

... and then if I do

'(guix-emacs-load-autoloads "/run/current-system/profile")'

'M-x magit-status' works.

>
> So to recap, you found 2 issues:
>
> 1. Emacs packages installed in a system profile are not automatically
>added to 'load-path'.
>
> 2. With the current EMACSLOADPATH, a wrong "site-lisp.el" is loaded, so
>"M-x guix-…" commands are not autoloaded.
>
> Both are easy to fix, thanks again for reporting!

My pleasure.

I am a little confused (not your fault). May I ask an off-topic
question?

It seems that doing ... 'M-x guix-edit foo.scm' ... amounts to hacking
guix.

However '8.1 Building from Git' says, "If you want to hack Guix itself,
it is recommended to use the latest version from the Git repository."
... and goes on to describe a different approach.

Can you comment on which approach is best for which situation.

TIA - George

bug#22304: Build for Julia is not reproducible

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> When building “julia” twice we get different binaries for
>>
>>   $out/lib/julia/sys.so
>>
>> and
>>
>>   $out/lib/julia/sys-debug.so
>
> Apparently there’s no __DATE__ and __TIME__ in the C code.
>
> I would check if the order of object files on the command line that
> links those shared objects is always the same.

As far as I could tell the order of shared objects in two consecutive
runs is the same.

~~ Ricardo

bug#22550: (require 'magit) produces error: "no such file or directory" "dash"

[Alex Kost]

myglc2 (2016-02-04 18:16 +0300) wrote:

[...]
> glc4@g1 ~$ echo $EMACSLOADPATH
> :/etc/emacs
>
> If I set it to match what you say ...
>
> glc4@g1 ~$ EMACSLOADPATH=/etc/emacs/site-start.el
> glc4@g1 ~$ emacs

No, no, it is expected; I meant ":/etc/emacs" is the default value,
sorry for the confusion.

[...]
> Note: below, I have EMACSLOADPATH=:/etc/emacs
>
>>> (require 'magit)
>>>
>>> ... generates this traceback ...
[...]
>> Yes, the problem is: currently only a user profile is "inspected" for
>> emacs packages, but not a system profile.  I didn't realize people could
>> install emacs packages globally, but apparently we should also check the
>> system profile as well.  Thanks for reporting!
>>
>>> Adding emac-dash to config.h.scm does not change the behavior.
>>
>> There is no need to install emacs-dash explicitly, as magit "propagates"
>> this library.  You can do "M-x guix-edit magit" to see that "dash" is in
>> "propagated-inputs".
>
> When I do  "M-x guix-edit" I get ...
>
> M-x guix-edit [No match]
>
> ... which is what lead me to believe I needed to fix load-path

No, there is no need to fix load-path; on GuixSD it should work
out-of-the-box; it doesn't work currently because there is a bug
introduced several days ago (see below).

>> Now could you try this after starting Emacs:
>>
>>   M-: (guix-emacs-load-autoloads "/run/current-system/profile")
>>
>> and check that "M-x magit-status" works after that?
>
> YES! That makes everything work.

Thanks for confirmation!

> So, should I put ...
>
> '(guix-emacs-load-autoloads "/run/current-system/profile")'
>
> ... in init.el, in which case guix INFO should say so.

Well, you can do it as a temporary workaround, but we'll fix it soon (I
mean the system profile will also be inspected for emacs packages), so
it will not be necessary in the closest future.

> Or, is there something wrong with EMACSLOADPATH?

Yes, I mean it's not a problem on your side, but it's bug in GuixSD. I
think we should change this value from ":/etc/emacs" to "/etc/emacs:".
The problem with the current EMACSLOADPATH is that "/etc/emacs" value is
appended to 'load-path' variable, but it should be prepended to it, so
that the proper "site-lisp.el" will be found.

Sorry, this bug was introduced recently and you are the first who faced
it :-)

Right now I can't check it, but I think if you start emacs like this:

  EMACSLOADPATH=/etc/emacs: emacs

you'll get "M-x guix-…" commands.  Could you confirm?

So to recap, you found 2 issues:

1. Emacs packages installed in a system profile are not automatically
   added to 'load-path'.

2. With the current EMACSLOADPATH, a wrong "site-lisp.el" is loaded, so
   "M-x guix-…" commands are not autoloaded.

Both are easy to fix, thanks again for reporting!

-- 
Alex

bug#22558: gnupg-2.1.11 on x86_64 failed its tests many times on Hydra

[Mark H Weaver]

gnupg-2.1.11 on x86_64 failed its tests many times on Hydra:

  http://hydra.gnu.org:3000/build/990803#tabs-buildsteps

On all other architectures (i686, armhf, mips64el) it succeeded on the
first try.  So far, we've heard no reports of it failing for anyone else
on x86_64.  Ludovic built it 3 times on his x86_64 machine and it never
failed.

It failed in at least two different ways:

* With only 1 test failure: gpgtar.test.  This happened on at least two
  different build slaves.

* With 14 test failures.  This happened at least twice, on
  hydra.gnunet.org.

I've attached 4 of the failure logs retrieved from Hydra.  There are two
logs of each of the two failure modes described above.

It would be good to understand what happened here.

 Mark




gnupg-2.1.11-x86_64-failure-logs.tar.xz
Description: hydra gnupg-x86_64 failure logs

bug#22558: gnupg-2.1.11 on x86_64 failed its tests many times on Hydra

[Mark H Weaver]

Eric Bavier found this:

  https://bugs.gnupg.org/gnupg/issue2229

Title: "make check 14 0f 35 tests failed"

 Mark


PS: It doesn't load in our IceCat with the error "Cannot communicate
securely with peer: no common encryption algorithm(s). (Error code:
ssl_error_no_cypher_overlap)", but it works in Epiphany.