bug#34211: error running container: mingetty cannot find ttys

[Giovanni Biscuolo]

Hi!

plase is there someone else that could reproduce this issue with "guix
system container": https://issues.guix.info/issue/34211 ?

I'm still not able to run a container built using "guix system container
container-minimal.scm -r container-minimal"

I'm on guix commit: 4aeb7f34c948f32363f2ae29c6942c6328df758c

this is the simple container.scm I'm using:

--8<---cut here---start->8---
;; This is an operating system configuration template
;; to test containers via guix system (also on foregin distros)
;; see 
https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-system.html

(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules screen ssh emacs)

(operating-system
  (host-name "test-container")
  (timezone "Europe/Rome")
  (locale "en_US.utf8")

  ;; Boot in "legacy" BIOS mode
  (bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda")))

  (file-systems (cons (file-system
(device (file-system-label "guixsd"))
(mount-point "/")
(type "ext4"))
  %base-file-systems))
  
  ;; This is where user accounts are specified.  The "root"
  ;; account is implicit, and is initially created with the
  ;; empty password.
  (users (cons (user-account
(name "gbiscuolo")
(comment "Giovanni Biscuolo (admin)")
(group "users")
(supplementary-groups '("wheel" "audio" "video"))
(home-directory "/home/gbiscuolo"))
   %base-user-accounts))
  
  ;; Globally-installed packages.
  (packages (cons* screen openssh emacs %base-packages))

  ;; Add services to the baseline: a DHCP client and
  ;; an SSH server.
  (services (cons* (service dhcp-client-service-type)
   (service openssh-service-type
(openssh-configuration
 (x11-forwarding? #t)
 (permit-root-login 'without-password)
 
 (port-number 22)))
   %base-services)))
--8<---cut here---end--->8---

and this are the messages I got on running the container:

--8<---cut here---start->8---
registering public key 
'/gnu/store/4v6cxail1ajinjqsgfblan132fbw06m4-guix-0.16.0-9.4bddd12/share/guix/hydra.gnu.org.pub'...
registering public key 
'/gnu/store/4v6cxail1ajinjqsgfblan132fbw06m4-guix-0.16.0-9.4bddd12/share/guix/berlin.guixsd.org.pub'...
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 
nscd: 166 monitoring file `/etc/hosts` (1)
nscd: 166 monitoring directory `/etc` (2)
nscd: 166 monitoring file `/etc/resolv.conf` (3)
nscd: 166 monitoring directory `/etc` (2)
nscd: 166 monitoring file `/etc/services` (4)
nscd: 166 monitoring directory `/etc` (2)
failed to start service 'console-font-tty1'
failed to start service 'console-font-tty2'
failed to start service 'console-font-tty3'
failed to start service 'console-font-tty4'
failed to start service 'console-font-tty5'
failed to start service 'console-font-tty6'
Feb  6 12:45:18 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[181]: 
tty3: No such file or directory
Feb  6 12:45:18 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[180]: 
tty4: No such file or directory
Feb  6 12:45:18 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[178]: 
tty6: No such file or directory
Feb  6 12:45:18 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[179]: 
tty5: No such file or directory
Feb  6 12:45:18 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[183]: 
tty1: No such file or directory
Feb  6 12:45:18 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[182]: 
tty2: No such file or directory
Feb  6 12:45:24 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[190]: 
tty4: No such file or directory
Feb  6 12:45:24 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[188]: 
tty6: No such file or directory
Feb  6 12:45:24 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[189]: 
tty5: No such file or directory
Feb  6 12:45:24 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[191]: 
tty3: No such file or directory
Feb  6 12:45:24 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[193]: 
tty1: No such file or directory
Feb  6 12:45:24 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[192]: 
tty2: No such file or directory
Feb  6 12:45:29 localhost 
/gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[

bug#33470: [bug#34249] [PATCH] guix package: Avoid spinner at end of output.

[Christopher Baines]

Ludovic Courtès  writes:

> Danny Milosavljevic  skribis:
>
>> Hi Christopher,
>>> diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
>>> index a633d2ee6d..4db0e72e9b 100644
>>> --- a/guix/scripts/package.scm
>>> +++ b/guix/scripts/package.scm
>>> @@ -159,6 +159,7 @@ hooks\" run when building the profile."
>>> (switch-symlinks profile (basename name))
>>> (unless (string=? profile %current-profile)
>>>   (register-gc-root store name))
>>> +   (display "\r") ; erase the spinner
>>
>> In order to actually erase it, might want to do (display "\r\x1b[K") instead.
>
> And to do that, you can use (erase-current-line port).
>
> Though actually I think this should be done in ‘print-build-event’ in
> (guix status).  Probably something like the patch below, but I haven’t
> been able to quickly reproduce the initial problem.
>
> Could you give it a spin (ah ha!) and report back?
>
> If it doesn’t solve the issue, we should strace the thing to see why it
> keeps spinning after everything is “done” basically.
>
> Thanks,
> Ludo’.
>
> diff --git a/guix/status.scm b/guix/status.scm
> index e3375816c5..7a330525b0 100644
> --- a/guix/status.scm
> +++ b/guix/status.scm
> @@ -465,8 +465,14 @@ addition to build events."
>  (_
>   (spin! port))
>
> -  (unless print-log?
> -(display "\r" port))  ;erase the spinner
> +  (define erase-current-line*
> +(if (isatty?* port)
> +(lambda (port)
> +  (erase-current-line port)
> +  (force-output port))
> +(const #t)))
> +
> +  (erase-current-line* port)  ;clear the spinner
>(match event
>  (('build-started drv . _)
>   (let ((properties (derivation-properties

I've tried out the change you pushed here [1], and it looks good to me
:) I can't see anything odd in the output now.

1: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=7473bce207af846312d5167a398f5f20bbf3e896


signature.asc
Description: PGP signature

bug#33285: Installing, then removing, a package yields a different profile

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Actually, to do things correctly, we should really store the .drv in the
> ‘manifest’ file.  That way, manifest entries would always contains a
> valid “lowerable” object (a package or a derivation record), as opposed
> to a store reference that happens to be valid.

On second thought that’s probably not a great idea: we’d retain
references to the .drv themselves, which can end up taking a bit of
space, especially if --gc-keep-outputs is in use.

So… the more I think about it the more I’m tempted to punt on this one.

The discrepancy we see here does not happen when using --manifest, which
is probably what matters most.

Thoughts?

Ludo’.

bug#33285: Installing, then removing, a package yields a different profile

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> Actually, to do things correctly, we should really store the .drv in the
>> ‘manifest’ file.  That way, manifest entries would always contains a
>> valid “lowerable” object (a package or a derivation record), as opposed
>> to a store reference that happens to be valid.
>
> On second thought that’s probably not a great idea: we’d retain
> references to the .drv themselves, which can end up taking a bit of
> space, especially if --gc-keep-outputs is in use.
>
> So… the more I think about it the more I’m tempted to punt on this one.
>
> The discrepancy we see here does not happen when using --manifest, which
> is probably what matters most.

I think it’s fine to leave it as it is, then.  “--install” and
“--remove” are stateful and should be expected to have quirks like this.
(E.g. upgrading Guix in between two “--install”s can lead to
a mosaic of a profile that could not be produced any other way.)

“--manifest” is the recommended way to get reproducible profile
generations, so if that’s working fine I’m okay with closing this as
wontfix.  Chris, what do you think?

Thanks for investigating!

--
Ricardo

bug#33470: bug#34249: [PATCH] guix package: Avoid spinner at end of output.

[Ricardo Wurmus]

Christopher Baines  writes:

> I've tried out the change you pushed here [1], and it looks good to me
> :) I can't see anything odd in the output now.
>
> 1: 
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=7473bce207af846312d5167a398f5f20bbf3e896

With this change I see that there are now two empty lines between
“downloading” lines.  The updating line flickers, too.

I wonder if maybe too much is deleted.  I can’t give specifics, but it
did seem a little weird when I observed the output on my i686 machine.

--
Ricardo

bug#27476: libguile/memoize.c is not thread safe, so syntax parameter expansion is not thread-safe

[Ludovic Courtès]

Hello Andy!

Since guix-core.drv is the best reproducer I have so far for this syntax
parameter crash, I modified (guix self) to print the name of the files
it’s compiling, and here’s the crash I got (on a 24-core machine):

--8<---cut here---start->8---
building /gnu/store/hf324mhj5607hh2izb01dzhwakmn8am8-guix-core.drv...
[ 39/ 78] loading...100.0% of 39 filesbuilding "guix/config.scm"
[ 39/ 78] compiling...0.0% of 39 filesbuilding "guix.scm"
[ 39/ 78] compiling...0.0% of 39 filesbuilding "guix/monad-repl.scm"
[ 39/ 78] compiling...0.0% of 39 filesbuilding "guix/store.scm"
[ 39/ 78] compiling...0.0% of 39 filesbuilding "guix/utils.scm"
[ 39/ 78] compiling...0.0% of 39 filesbuilding "guix/memoization.scm"
[ 39/ 78] compiling...0.0% of 39 filesbuilding "guix/profiling.scm"
[ 39/ 78] compiling...0.0% of 39 filesbuilding "guix/build/utils.scm"
[ 39/ 78] compiling...0.0% of 39 filesbuilding "guix/build/syscalls.scm"
[ 40/ 78] compiling...2.6% of 39 filesbuilding "guix/deprecation.scm"
[ 41/ 78] compiling...5.1% of 39 filesbuilding "guix/i18n.scm"
[ 42/ 78] compiling...7.7% of 39 filesbuilding "guix/serialization.scm"
[ 43/ 78] compiling...   10.3% of 39 filesbuilding "guix/combinators.scm"
[ 44/ 78] compiling...   12.8% of 39 filesbuilding "guix/monads.scm"
[ 45/ 78] compiling...   15.4% of 39 filesbuilding "guix/records.scm"
[ 46/ 78] compiling...   17.9% of 39 filesIn ice-9/psyntax.scm:
  2338:44 19 (expand-let _ _ _ ((line . 447) (column . 6) (filename . 
"./guix/monads.scm")) _ # 
_ _ _)
  1679:45 18 (parse _ _ _ _ _ _ _)
In ice-9/boot-9.scm:
   222:17 17 (map1 "placeholder" placeholder) ("l-10a3c941d34314a1-4889" 
lexical . failure-10a3c941d34314a1-488a) ("placeholder" placeholder) 
("placeholder" placeholder) ("l-10a3c9?" . #) ?) ?)))
In ice-9/psyntax.scm:
  1409:12 16 (_ _ _ #)>)
  2338:44 15 (expand-let _ _ _ ((line . 447) (column . 6) (filename . 
"./guix/monads.scm")) (hygiene guix monads) # _ _ ((# ?)))
  1679:45 14 (parse _ _ _ _ _ _ _)
In ice-9/boot-9.scm:
   222:17 13 (map1 "l-10a3c941d34314a1-4894" macro . #) ("placeholder" placeholder) 
("l-10a3c941d34314a1-488f" lexical . #) ("l-10?" . #) ?) . #)))
In ice-9/psyntax.scm:
  2338:44 12 (expand-let _ _ _ ((line . 447) (column . 6) (filename . 
"./guix/monads.scm")) (hygiene guix monads) # _ _ ((# ?)))
  1679:45 11 (parse _ _ _ _ _ _ _)
In ice-9/boot-9.scm:
   222:17 10 (map1 "l-10a3c941d34314a1-48b0" macro . #) ("placeholder" placeholder) 
("l-10a3c941d34314a1-48ac" lexical . #) ("l-10?" . #) ?) . #)))
In ice-9/psyntax.scm:
  2338:44  9 (expand-let _ _ _ ((line . 447) (column . 6) (filename . 
"./guix/monads.scm")) (hygiene guix monads) # _ _ ((# ?)))
  1612:33  8 (parse "placeholder" placeholder) ("l-10a3c941d34314a1-48c8" 
lexical . tail-10a3c941d34314a1-48c9) ("l-10a3c941d34314a1-48b0" macro . 
#) ?) . #)) ?)
  1348:32  7 (syntax-type (>>= (mproc head result) (lambda (result) (loop tail 
result))) (("placeholder" placeholder) ("l-10a3c941d34314a1-48c8" lexical . 
tail-10a3c941d34314a1-48c9) ("l-?" . #) ?) ?)
  1559:32  6 (expand-macro # _ 
_ _ _ _ _)
In ice-9/boot-9.scm:
   752:25  5 (dispatch-exception _ _ _)
   751:25  4 (dispatch-exception 1 syntax-error (>>= ">>= (bind) used outside 
of 'with-monad'" ((line . 451) (column . 9) (filename . "./guix/monads.scm")) 
(>>= (mproc head result) (lambda # ?)) #))
In guix/build/compile.scm:
122:6  3 (_ _ . _)
In ice-9/boot-9.scm:
829:9  2 (catch #t # 
# _)
In guix/build/compile.scm:
   125:21  1 (_)
In unknown file:
   0 (make-stack #t)
guix/build/compile.scm:125:21: Syntax error:
./guix/monads.scm:452:9: >>=: >>= (bind) used outside of 'with-monad' in form 
(>>= (mproc head result) (lambda (result) (loop tail result)))
builder for `/gnu/store/hf324mhj5607hh2izb01dzhwakmn8am8-guix-core.drv' failed 
with exit code 1
--8<---cut here---end--->8---

Here (guix monads) was already loaded before, but it’s only when
compiling (guix monads), so after it had been loaded, that we get the
error.  The syntax parameter in question is defined in (guix monads)
itself.

I drew the conclusion that our syntax parameter is redefined when we
compile or when we load (guix monads), so there’s a chance that we get
to see the wrong value when we expand (guix monads) (I’m not entirely
sure about the exact sequence of events.)

So I came up with ‘define-syntax-parameter-once’, which is like
‘define-once’ but for syntax parameters (note that we can’t use
‘define-once’ in ‘define-syntax-parameter-once’ because it expands to a
reference to NAME, which doesn’t work for a macro):

diff --git a/guix/monads.scm b/guix/monads.scm
index 6ae616aca9..1bbf79c8ba 100644
--- a/guix/monads.scm
+++ b/guix/monads.scm
@@ -274,12 +274,20 @@ more optimizations."
(_
 #'generic-name))
 
-(define-syntax-parameter >>=
+(define-syntax-rule (define-syntax-

bug#27476: libguile/memoize.c is not thread safe, so syntax parameter expansion is not thread-safe

[Andy Wingo]

Hi!

On Wed 06 Feb 2019 15:48, Ludovic Courtès  writes:

> I drew the conclusion that our syntax parameter is redefined when we
> compile or when we load (guix monads), so there’s a chance that we get
> to see the wrong value when we expand (guix monads) (I’m not entirely
> sure about the exact sequence of events.)

You are a wizard

To be clear, here's the series of events.  Firstly, know that defining a
syntax parameter is like:

  (define name
(make-syntax-transformer 'name 'syntax-parameter (list f)))

So at the top level you end up with an association between a name and a
"syntax transformer" object (see macros.[ch]).  The syntax transformer
object itself consists of its name (for debugging), its syntax type, and
its syntax binding.

For syntax parameters, the binding is a list containing a single
element, the syntax transformer.  This list is later used as a key into
a compile-time environment, as it's a unique object associated with the
syntax parameter.

When (syntax-parameterize ((name f*)) exp) is seen, psyntax will look up
`name' in the current expansion-time environment.  It asserts that the
name is bound to a syntax transformer and that the syntax transformer is
indeed a syntax parameter, and extracts the associated binding `b'.
Keep in bind that `b' is the single-element list containing the
"default" syntax transformer `f'.

syntax-parameterize then does something weird: it adds an association
between the binding value `b' and `f*' to the expand-time environment.
It does this because the `b' is just a fresh object, so it's a unique
key that's usable for associations.  (The way this works is my fault
FWIW.)  To be clear, it doesn't add a new definition of `name'; it
instead establishes a new lexical binding for the unique object `b'.

Then when a use of `name' is seen within `exp', Guile finds that `name'
is a syntax parameter, extracts the binding from the syntax transformer
object, then does a second lookup of that binding.  If it finds
something bound, it uses that, otherwise it uses the default binding.

I think you see the race here.  For an initial state of

(define P (stx-param (list F)))

we have:

   thread A   thread B
time
resolve P |
extract B |
associate B and F*|
  |   define P (stx-param (list F**))
resolve P |
extract B (!) |
resolve B (!) |
see F** instead of F* (!) |
  v

> So I came up with ‘define-syntax-parameter-once’, which is like
> ‘define-once’ but for syntax parameters (note that we can’t use
> ‘define-once’ in ‘define-syntax-parameter-once’ because it expands to a
> reference to NAME, which doesn’t work for a macro):

Your fix is good!  But, it prevents redefinition of syntax parameters.

I would like to work on a solution that instead of using this
double-lookup, simply adds an association between P and F* in the
environment, instead of doing the double-lookup thing.  Probably that
will be 3.0-only.

For 2.2, we can probably update the compiler to trampoline through some
kind of "redefine-syntax" or something that will do (set-car! B F**)
instead of (define P (stx-param B*)).  I.e. redefinition keeps the
unique key there.

Andy

bug#24981: [Website] All pages fail the HTML validation test

[sirgazil]

Hi,

This issue is solved in the website repository now. The following 
commits fix remaining validation errors related to the use of the 
obsolete TT element:


 * 13a1a5a41df9eae7d3ca54c6ab4774c7804dba45
   

 * 38ba9baa9162e4060160c03d0827787c9f52e26c
   


And the following commit fixes a validation error related to using a P 
element as a container of DIV elements:


b951df49798db870aab5ebd4c63d70d2d0c6c8cf 



I think once these changes are deployed to gnu.org and guix.info this 
issue can be closed.


P. S.: I would deploy it myself, but I don't remember how to do it in 
the case of gnu.org, and I don't have information about guix.info.


:)

bug#34243: update cmake to latest release (3.13.3)

[Marius Bakke]

Maxim Cournoyer  writes:

> Hello,
>
> Clément Lassieur  writes:
>
>> Marius Bakke  writes:
>>
>>> Clément Lassieur  writes:
>>>
 This is a wish. :-)
>>>
>>> Will 3.13.1 from 'staging' do?
>>
>> Yes sure!  I hadn't checked staging.  Thanks you :-)
>
> Maybe now would be a good time to merge this patch, along this version
> bump:  http://issues.guix.info/issue/33497 ?  It adds manpages and an
> info manual (+ HTML docs in the doc output).

Staging is already fully-built for all architectures, and usually does
not take packages with more than ~1200 dependents, so that patch will
have to go to core-updates (which should be starting soonish)...  :-)


signature.asc
Description: PGP signature

bug#27476: libguile/memoize.c is not thread safe, so syntax parameter expansion is not thread-safe

[Ludovic Courtès]

Hi!

Andy Wingo  skribis:

> To be clear, here's the series of events.  Firstly, know that defining a
> syntax parameter is like:

Thanks for the clear explanation!

>> So I came up with ‘define-syntax-parameter-once’, which is like
>> ‘define-once’ but for syntax parameters (note that we can’t use
>> ‘define-once’ in ‘define-syntax-parameter-once’ because it expands to a
>> reference to NAME, which doesn’t work for a macro):
>
> Your fix is good!  But, it prevents redefinition of syntax parameters.

Yes.  It’s acceptable in this case, so I’ve pushed it as a workaround as
commit 8245bb74fc7bdcdc2f9d458057cefc9cd982e489 in Guix.

> I would like to work on a solution that instead of using this
> double-lookup, simply adds an association between P and F* in the
> environment, instead of doing the double-lookup thing.  Probably that
> will be 3.0-only.
>
> For 2.2, we can probably update the compiler to trampoline through some
> kind of "redefine-syntax" or something that will do (set-car! B F**)
> instead of (define P (stx-param B*)).  I.e. redefinition keeps the
> unique key there.

Sounds good.  Are you taking a look at this?

Perhaps that’d be a good excuse to release 2.2.5.

Thank you!

Ludo’.

bug#26752: Ansible & others' problems with wrapped '.ansible-real' scripts

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>> Jelle Licht  skribis:
>>
>>> The current ansible package is still brokenin the same way.
>>>
>>> Is there already an acceptable way of working around this problem?
>>> Otherwise I could send my (extremely hacky) workaround that adds a specific
>>> condition in the ansible source code to check for .ansible-real.
>>
>> For now I think we have to go with the hack.  Make sure to add a comment
>> linking to this bug report.
>
> There is a way to get around this.  It’s presented in #29951:
>
> https://issues.guix.info/issue/29951

BTW, there’s also this patch series on this topic:

  https://issues.guix.info/issue/27003

What to do?

Ludo’.