bug#30467: GuixSD fails to display login prompt on headless server

[George myglc2 Clemmer]

In my previous message, please disregard comments that begin with ...

> So I tried that with a build from today (guix (GNU Guix)
> 0.13.0.5116-e272), and *no login* is raised on ttyS1 (My G46, sys.scm
> attached).

which is mistakenly based on an old commit :-|

bug#30467: GuixSD fails to display login prompt on headless server

[George myglc2 Clemmer]

Hi Danny,

I think we got side-tracked to the serial port when my real issue is
with the VGA port. Maybe my bug report was not clear. Let me clarify ...

My headless server stopped displaying the console tty login *on the VGA
port* somewhere between (GNU Guix) 0.13.0.4589-74bea6 (my G18) and (GNU
Guix) 0.13.0.5042-6e385 (My G19). In the later version, when I reboot
the VGA displays 1) the BIOS prompt, 2) the grub boot menu, 3) "Booting
GNU with Linuxlibre ..." for a couple seconds, and then 4) a blank.

In either version, this config ...

(agetty-service (agetty-configuration (tty "ttyS1")
(baud-rate "115200")))

... causes a login prompt to be raised on ttyS1 which, on my system, is
mapped to IPMI Serial over Lan (SOL). However recently you said ...

On 02/15/2018 at 15:54 Danny Milosavljevic writes:

> In the long run please remove your agetty-service, it should automatically 
> appear
> (it recovers the settings from the "console" kernel-argument).

So I tried that with a build from today (guix (GNU Guix)
0.13.0.5116-e272), and *no login* is raised on ttyS1 (My G46, sys.scm
attached).

However, if I *ignore your advice* a login prompt *is raised* on ttyS1
(My G45).

So, IIUC, it's not working the way you said it would, but it's not a
problem for me because I can just use the agetty-service.

Not sure your questions are still relevant, but here is what I see ...

On 02/17/2018 at 17:05 Danny Milosavljevic writes:

> What does
>
> stty -F /dev/ttyS1
>
> say?

g1@g1 ~/www$ sudo stty -F /dev/ttyS1
speed 115200 baud; line = 0;
-brkint -imaxbel

On 02/17/2018 at 17:04 Danny Milosavljevic writes:

> Huh, please try
>
> strace -f agetty /dev/ttyS1 >log 2>&1
>
> and send the log to the list...

(log.gz attached)

HTH - George



log.gz
Description: Binary data


sys.scm
Description: Binary data

bug#30537: glibc 2.26 refuses to run on CentOS 6.8

[Mark H Weaver]

Hi Ricardo,

Ricardo Wurmus  writes:

> Ricardo Wurmus  writes:
>
>> Here’s a patch to graft the glibc to apply the patch to allow the 2.6.32
>> kernel.  I’m going to apply this at work now.
>
> That patch had a couple of problems.  Here’s a new version.

[...]

> diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
> index b2c1d232f..111bbbcec 100644
> --- a/gnu/packages/base.scm
> +++ b/gnu/packages/base.scm
> @@ -12,6 +12,7 @@
>  ;;; Copyright © 2017 Mathieu Othacehe 
>  ;;; Copyright © 2017 Marius Bakke 
>  ;;; Copyright © 2017 Eric Bavier 
> +;;; Copyright © 2018 Ricardo Wurmus 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -537,6 +538,7 @@ store.")
> ;; Note: Always use a dot after the minor version since various places 
> rely
> ;; on "version-major+minor" to determine where locales are found.
> (version "2.26.105-g0890d5379c")
> +   (replacement glibc-2.26-patched)
> (source (origin
>  (method url-fetch)
>  (uri (string-append "https://alpha.gnu.org/gnu/guix/mirror/";
> @@ -839,10 +841,20 @@ GLIBC/HURD for a Hurd host"
>  ;; Below are old libc versions, which we use mostly to build locale data in
>  ;; the old format (which the new libc cannot cope with.)
>  
> +(define glibc-2.26-patched
> +  (package
> +(inherit glibc)
> +(replacement #f)
> +(source (origin
> +  (inherit (package-source glibc))
> +  (patches (cons (search-patch "glibc-allow-kernel-2.6.32.patch")
> + (origin-patches (package-source glibc
> +
>  (define-public glibc-2.25
>(package
>  (inherit glibc)
>  (version "2.25")
> +(replacement #f)
>  (source (origin
>(inherit (package-source glibc))
>(uri (string-append "mirror://gnu/glibc/glibc-"
> @@ -862,6 +874,7 @@ GLIBC/HURD for a Hurd host"
>(package
>  (inherit glibc)
>  (version "2.24")
> +(replacement #f)
>  (source (origin
>(inherit (package-source glibc))
>(uri (string-append "mirror://gnu/glibc/glibc-"
> @@ -882,6 +895,7 @@ GLIBC/HURD for a Hurd host"
>(package
>  (inherit glibc)
>  (version "2.23")
> +(replacement #f)
>  (source (origin
>(inherit (package-source glibc))
>(uri (string-append "mirror://gnu/glibc/glibc-"
> @@ -905,6 +919,7 @@ GLIBC/HURD for a Hurd host"
>(package
>  (inherit glibc)
>  (version "2.22")
> +(replacement #f)
>  (source (origin
>(inherit (package-source glibc))
>(uri (string-append "mirror://gnu/glibc/glibc-"

These (replacement #f) fields should not be needed.  'replacement' is
now an 'innate' field of the package record type, which means that it is
not inherited.

> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
> index 7286e954c..db43691fd 100644
> --- a/gnu/packages/commencement.scm
> +++ b/gnu/packages/commencement.scm
> @@ -4,6 +4,7 @@
>  ;;; Copyright © 2012 Nikita Karetnikov 
>  ;;; Copyright © 2014, 2015, 2017 Mark H Weaver 
>  ;;; Copyright © 2017, 2018 Efraim Flashner 
> +;;; Copyright © 2018 Ricardo Wurmus 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -486,7 +487,7 @@ the bootstrap environment."
>;; built just below; the only difference is that this one uses the
>;; bootstrap Bash.
>(package-with-bootstrap-guile
> -   (package (inherit glibc)
> +   (package/inherit glibc
>   (name "glibc-intermediate")
>   (arguments
>`(#:guile ,%bootstrap-guile
> @@ -664,7 +665,7 @@ exec ~a/bin/~a-~a -B~a/lib -Wl,-dynamic-linker -Wl,~a/~a 
> \"$@\"~%"
>  
>  (define glibc-final
>;; The final glibc, which embeds the statically-linked Bash built above.
> -  (package (inherit glibc-final-with-bootstrap-bash)
> +  (package/inherit glibc-final-with-bootstrap-bash
>  (name "glibc")
>  (inputs `(("static-bash" ,static-bash-for-glibc)
>,@(alist-delete

We seem to be oscillating on the question of whether to graft these
early GLIBCs.  In June 2017, I switched to using 'package/inherit' here
in commit 13f7f2fd2b208c29361ef2290f55911879a6adf2, and in October those
changes were reverted in commit 848f550f2c105326dc3be4033c8aaf35ec21cde4
by Efraim, although I'm not sure why.

It'll be painful to have *everything* grafted until the next
core-updates cycle, but I suppose it's necessary.

  Thanks,
Mark

bug#30505: Starting console/terminal Unicode support

[Danny Milosavljevic]

Hi Ludo,

On Wed, 21 Feb 2018 23:21:34 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> >> This ‘unicode-start’ procedure is essentially a port of the
> >> ‘unicode_start’ script from ‘kbd’.  I suppose the justification is to
> >> make sure we’re using UTF-8 input regardless of what the kernel defaults
> >> or command-line options are.  

Yeah, but the only way to have it not use utf-8 would be to explicitly pass
"default_utf8=0" as a command-line parameter.  I think at that point the
user deserves what he personally asked for :P

>In
> other cases (custom kernel build with different defaults, different
> kernel command-line settings, etc.), we’d just get it wrong with things
> breaking down the path, no?

Yes, it would just default to ASCII.  In the big scheme of things it's not so 
bad.

I just thought that if it causes trouble *and* it's not needed anymore, the
simplest way is to just remove it.

> Also, FWIW, systemd’s vconsole-setup.c does exactly that:
> 
>   
> https://github.com/systemd/systemd/blob/master/src/vconsole/vconsole-setup.c#L94

Huh, I wonder why they do it.  systemd is quite new.  I understand that older 
stuff
(like kbd) did it because they had to in the Linux 2.4 days - but this?

We should ask them...

Aha, they also have

static int toggle_utf8_sysfs(bool utf8) {
int r;

r = write_string_file("/sys/module/vt/parameters/default_utf8", 
one_zero(utf8), 0);
if (r < 0)
return log_warning_errno(r, "Failed to %s sysfs UTF-8 flag: 
%m", enable_disable(utf8));

log_debug("Sysfs UTF-8 flag %sd", enable_disable(utf8));
return 0;
}

so we could in fact directly force the VT driver to do our bidding, or even
check what's up before trying to write the 'G' (the latter sounds like a hack
hiding the actual problem, though).

bug#30569: Packages count as installed twice

[Andreas Enge]

On Wed, Feb 21, 2018 at 11:14:21PM +0100, Ricardo Wurmus wrote:
> Even so, you’ll have a file called “manifest” in the profile directory.
> This is unrelated to whether you used a manifest to create the profile
> or not.

I see! Yes, it appeared twice.

On Wed, Feb 21, 2018 at 05:14:58PM -0500, Leo Famulari wrote:
> It would be interesting to see the profile history. Was the second
> gnutls introduced after the first one, or were they introduced together?

Unfortunately I cannot tell any more. I only kept the last ten profiles,
and all of the corresponding manifest entries contain two copies of the
same gnutls. Once both of them were updated.

Andreas

bug#30505: Starting console/terminal Unicode support

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> On Mon, 19 Feb 2018 21:35:05 +0100
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> > It was a bad idea to do the "\x1b%G" in the first place.  
>> 
>> Because it’s redundant with IUTF8?
>
> I meant because the Linux kernel does it already and it's better not to
> have random multi-byte racy writes onto the tty while the mingetty
> is starting up (and possibly buffering and pending half of another sequence).

That ‘unicode-start’ code run when the ‘console-font-ttyN’ service is
started, right after ‘term-ttyN’ (mingetty) is up.  You’d hope mingetty
is really up and running once ‘term-ttyN’ is up, no?

> As far as I understand it's not redundant to do both.
>
> According to src/Linux/linux-4.12-rc2/drivers/tty/vt/vt.c, the 'G' controls
> the conversion utf-8->unicode that happens before the virtual terminal
> displays a corresponding character on the screen.
>
> On the other hand, the termios iutf8 is meant for the program running in the 
> session.

OK, I see.

> Say you have bash on vt1, then bash can check termios for the settings and 
> find
> out whether vt1 is UTF-8-capable (also has other settings like whether the
> terminal already supports line editing etc - old-school terminals were quite
> cool; a friend of mine salvaged a real one ^^).
>
> Note that drivers/tty/vt/vt.c only copies ONE way, from the 'G' flag to the
> termios (and that seldomly).
> Makes sense since the programs shouldn't have a say in what the terminal can 
> do :)
>
> So I'd say guix services fiddling with termios is ... weird and the 'G' 
> slightly
> less weird.

[...]

>> This ‘unicode-start’ procedure is essentially a port of the
>> ‘unicode_start’ script from ‘kbd’.  I suppose the justification is to
>> make sure we’re using UTF-8 input regardless of what the kernel defaults
>> or command-line options are.
>
> Yeah, but it's asking for trouble.
>
> I just checked Linux 2.6.32.1, it defaults to utf8 (IUTF8 in termios, and 
> 'G').
>
> I'd suggest to remove both.

When we’re using the defaults, I understand both are unnecessary.  In
other cases (custom kernel build with different defaults, different
kernel command-line settings, etc.), we’d just get it wrong with things
breaking down the path, no?

Also, FWIW, systemd’s vconsole-setup.c does exactly that:

  
https://github.com/systemd/systemd/blob/master/src/vconsole/vconsole-setup.c#L94

And again that corresponds to the ‘unicode_start’ script.

Thoughts?

Ludo’.

bug#30569: Packages count as installed twice

[Leo Famulari]

On Wed, Feb 21, 2018 at 10:34:53PM +0100, Andreas Enge wrote:
> $ ./pre-inst-env guix package -r gnutls -i gnutls
> guile: warning: failed to install locale
> warning: failed to install locale: Invalid argument
> guix package: warning: Consider running 'guix pull' followed by
> 'guix package -u' to get up-to-date packages and security updates.
> 
> The following packages will be removed:
>gnutls 3.5.13  
> /gnu/store/g09is0bw144d8zrd059fiarqmjq7vr8a-gnutls-3.5.13
>gnutls 3.5.13  
> /gnu/store/g09is0bw144d8zrd059fiarqmjq7vr8a-gnutls-3.5.13
> 
> The following package will be upgraded:
>gnutls 3.5.13 -> 3.5.13
> /gnu/store/g09is0bw144d8zrd059fiarqmjq7vr8a-gnutls-3.5.13

It would be interesting to see the profile history. Was the second
gnutls introduced after the first one, or were they introduced together?


signature.asc
Description: PGP signature

bug#30569: Packages count as installed twice

[Ricardo Wurmus]

Andreas Enge  writes:

> On Wed, Feb 21, 2018 at 08:52:28PM +0100, Ricardo Wurmus wrote:
>> Does the package appear twice in the profile’s “manifest” file
>> (e.g. ~/.guix-profile/manifest)?
>
> no, I am not using a manifest and do things by hand all the time.

Even so, you’ll have a file called “manifest” in the profile directory.
This is unrelated to whether you used a manifest to create the profile
or not.

(This is the second naming conflict in Guix.  The other is “services”
for system services and shepherd services.)

-- 
Ricardo

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

bug#30522: Guile-SSH retries upon “guile --listen” failure to start

[Ludovic Courtès]

Hello Artyom & Marius,

Marius Bakke  skribis:

> Ludovic Courtès  writes:
>
>>> It would still be good with a better failure mode, but I'll file this
>>> under "pebkac" for now.
>>
>> Yes, I’m surprised it ended up looping.  Did you try to strace it or
>> something to see what was going on?  Perhaps guile failed to start
>> altogether and Guile-SSH kept retrying?
>
> Indeed.  Guile-SSH kept trying to start `guile --listen` over and over.

Artyom, do you think we could arrange for Guile-SSH to properly detect
failure to start ‘guile --listen’ and report it instead of retrying?

Perhaps it could check the exit code of ‘guile --listen’ and distinguish
127 (“command not found”) from other exit codes?

(For more context, see .)

Thanks,
Ludo’.

bug#30569: Packages count as installed twice

[Andreas Enge]

Hello,

On Wed, Feb 21, 2018 at 08:52:28PM +0100, Ricardo Wurmus wrote:
> Does the package appear twice in the profile’s “manifest” file
> (e.g. ~/.guix-profile/manifest)?

no, I am not using a manifest and do things by hand all the time.

> I’m not sure how it could have ended up there, but one possibility might
> be that you had two different versions of gnutls and they have both been
> upgraded to the latest version.

This is a plausible explanation.

I ended up running this command:

$ ./pre-inst-env guix package -r gnutls -i gnutls
guile: warning: failed to install locale
warning: failed to install locale: Invalid argument
guix package: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.

The following packages will be removed:
   gnutls   3.5.13  
/gnu/store/g09is0bw144d8zrd059fiarqmjq7vr8a-gnutls-3.5.13
   gnutls   3.5.13  
/gnu/store/g09is0bw144d8zrd059fiarqmjq7vr8a-gnutls-3.5.13

The following package will be upgraded:
   gnutls   3.5.13 -> 3.5.13
/gnu/store/g09is0bw144d8zrd059fiarqmjq7vr8a-gnutls-3.5.13

Then I ended up with only one listed.

Anyway, I do not think it did any harm, but it could indicate a bug somewhere
in the code.

Andreas

bug#30569: Packages count as installed twice

[Ricardo Wurmus]

Hi Andreas,

> trying to upgrade my packages, I notice something curious:
>
> $ ./pre-inst-env guix package -n -u
> The following packages would be upgraded:
> ...
>gnutls 3.5.13 -> 3.5.13
> /gnu/store/1ah3fd12w6v66q6yjdmd39xbisqi0gpw-gnutls-3.5.13
>gnutls 3.5.13 -> 3.5.13
> /gnu/store/1ah3fd12w6v66q6yjdmd39xbisqi0gpw-gnutls-3.5.13
> ...

Does the package appear twice in the profile’s “manifest” file
(e.g. ~/.guix-profile/manifest)?

I’m not sure how it could have ended up there, but one possibility might
be that you had two different versions of gnutls and they have both been
upgraded to the latest version.

--
Ricardo

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

bug#30569: Packages count as installed twice

[Andreas Enge]

Hello,

trying to upgrade my packages, I notice something curious:

$ ./pre-inst-env guix package -n -u
The following packages would be upgraded:
...
   gnutls   3.5.13 -> 3.5.13
/gnu/store/1ah3fd12w6v66q6yjdmd39xbisqi0gpw-gnutls-3.5.13
   gnutls   3.5.13 -> 3.5.13
/gnu/store/1ah3fd12w6v66q6yjdmd39xbisqi0gpw-gnutls-3.5.13
...

There is twice the exactly same package!

$ ./pre-inst-env guix package -I gnutls
gnutls  3.5.13  out 
/gnu/store/g09is0bw144d8zrd059fiarqmjq7vr8a-gnutls-3.5.13
gnutls  3.5.13  out 
/gnu/store/g09is0bw144d8zrd059fiarqmjq7vr8a-gnutls-3.5.13

This looks like a bug to me...

Andreas

bug#30562: "guix import pypi" fails now with "guix pulled" guix.

[Danny Milosavljevic]

Hi Marius,

On Wed, 21 Feb 2018 02:19:34 +0100
Marius Bakke  wrote:

> > ERROR: ERROR: Wrong type to apply: #  
> 
> Is this on a foreign distro?  I can't reproduce this on GuixSD.

No, it's on GuixSD - the update of the actual derivation from master is still
running, although guix pull is done.

$ echo $GUILE_LOAD_PATH
/home/dannym/.guix-profile/share/guile/site/2.2:/run/current-system/profile/share/guile/site/2.2
$ echo $GUILE_LOAD_COMPILED_PATH
/home/dannym/.guix-profile/lib/guile/2.2/site-ccache:/home/dannym/.guix-profile/share/guile/site/2.2:/run/current-system/profile/lib/guile/2.2/site-ccache:/run/current-system/profile/share/guile/site/2.2

bug#30526: java-testng: non-deterministic test failures

[Gábor Boskovits]

2018-02-21 10:07 GMT+01:00 Gábor Boskovits :

> 2018-02-19 14:55 GMT+01:00 Ricardo Wurmus :
>
>> Sometimes I get this error when building java-testng 6.14.2:
>>
>> --8<---cut here---start->8---
>> ===
>> TestNG
>> Total tests run: 1630, Failures: 1, Skips: 0
>> ===
>>
>> Failures in  :TestNG,  :Regression2
>> test.testng387.TestNG387.testInvocationCounterIsCorrectForMe
>> thodWithDataProvider()
>> StackTrace:
>>  java.lang.AssertionError: Arrays do not have the same size:3 != 4
>> at 
>> test.testng387.TestNG387.testInvocationCounterIsCorrectForMethodWithDataProvider(Unknown
>> Source)
>> ... Removed 27 stack frames
>>
>> phase `check' failed after 297.3 seconds
>> --8<---cut here---end--->8---
>>
>>
>>
> This actually seems to be known upstream, I consider reopening this bug:
> https://github.com/cbeust/testng/issues/582.
> It seems they just disabled the failing tests. I guess we should do the
> same.
>

I contacted upstream, and asked the status of this. I will report back when
they say something.


>
>
>> --
>> Ricardo
>>
>> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
>> https://elephly.net
>>
>>
>>
>>
>>
>

bug#30526: java-testng: non-deterministic test failures

[Gábor Boskovits]

2018-02-19 14:55 GMT+01:00 Ricardo Wurmus :

> Sometimes I get this error when building java-testng 6.14.2:
>
> --8<---cut here---start->8---
> ===
> TestNG
> Total tests run: 1630, Failures: 1, Skips: 0
> ===
>
> Failures in  :TestNG,  :Regression2
> test.testng387.TestNG387.testInvocationCounterIsCorrect
> ForMethodWithDataProvider()
> StackTrace:
>  java.lang.AssertionError: Arrays do not have the same size:3 != 4
> at test.testng387.TestNG387.testInvocationCounterIsCorrect
> ForMethodWithDataProvider(Unknown Source)
> ... Removed 27 stack frames
>
> phase `check' failed after 297.3 seconds
> --8<---cut here---end--->8---
>
>
>
This actually seems to be known upstream, I consider reopening this bug:
https://github.com/cbeust/testng/issues/582.
It seems they just disabled the failing tests. I guess we should do the
same.


> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>
>
>

bug#30566: While searching for packages, deprecated packages should be ignored

[Björn Höfling]

When I search for a deprecated package, I get both the deprecated
package and the new one. That is quite confusing and I can't decide
which one to take. For example:

$ guix package -s geiser

name: geiser-next
version: 0.9
outputs: out
systems: x86_64-linux i686-linux armhf-linux aarch64-linux
mips64el-linux dependencies: emacs-minimal-25.3 guile-2.0.14
location: guix/packages.scm:335:2
homepage: https://nongnu.org/geiser/
license: Modified BSD
synopsis: Collection of Emacs modes for Guile and Racket hacking  
description:
[..]
relevance: 6

name: geiser
version: 0.9
outputs: out
systems: x86_64-linux i686-linux armhf-linux aarch64-linux
mips64el-linux dependencies: emacs-minimal-25.3 guile-2.0.14
location: gnu/packages/emacs.scm:314:2
homepage: https://nongnu.org/geiser/
license: Modified BSD
synopsis: Collection of Emacs modes for Guile and Racket hacking  
description: 
[..]
relevance: 6

Here I get two exactly same results, besides the package name and the
source code line number.

I have to look into the package sources to find out which of the two is
the not-deprecated one.

As a user, I would like to see only the new package mentioned. Maybe
some users also want a short note like:

"geiser formerly known as geiser-new."

Technical background:

`deprecated-package` is defined in `guix/packages.scm`: 

```
(define (deprecated-package old-name p)
  "Return a package called OLD-NAME and marked as superseded by P, a package
object."
  (package
(inherit p)
(name old-name)
(properties `((superseded . ,p)
```

That means the `guix package -s` should somehow make use of the
`superseeded` property.

Björn