bug#57068: Resizing mcron job in vm-image.tmpl interferes with settings

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> Commit 945ad48cd8029fa77a643e00c7fd350e98cacca0 added an mcron job to
>> ‘vm-image.tmpl’ that resets screen size every second.  I’m don’t fully
>> understand the problem this was addressing, but it has two drawbacks:
>>
>>   1. Kicking in every second is inefficient.
>>
>>   2. Resetting the screen size prevents users from changing it.  For
>>  example, if I run:
>>
>>$(guix system vm gnu/system/examples/vm-image.tmpl) -m 1024
>>
>> then go to the Xfce menu, Settings -> Display, and change the screen
>> size, I have it immediately reset back to the default value.
>
> There’s a third problem that I initially thought was unrelated:
>
>   3. The mcron job starts running before ‘xorg-server’ is up, and that
>  can cause Xorg to fail to start.
>
> Namely, if you run the command above, you’ll see that Xorg starts and
> fails typically a few times in a row, until it eventually succeeds.  In
> /var/log/messages, you can see that the ‘xorg-server’ process exits with
> code 1 (without any indication of what went wrong AFAICS) and the
> service gets respawned.
>
> Now if you remove the mcron job and boot the VM, the ‘xorg-server’
> service successfully starts.  It’s 100% reproducible for me.

I tried to reproduce the problem without any luck on my machine (it
always boots fine).  Odd.

I don't mind the hack removed, but I think we should aim to keep SPICE
dynamic resizing working, and currently that'd mean switching desktop
environment, unless we fix
https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/142 (GNOME had
adjusted for the years old change in SPICE with
https://gitlab.gnome.org/GNOME/mutter/-/commit/957513242c26be458be7a101b83180e3f59f6a44),
in case your looking for something fun to hack on :-).

Thanks,

Maxim

bug#57052: elogind-service specifies a variable that's ignored by defualt

[Maxim Cournoyer]

Hello,

Cairn  writes:

> Would it not still be explicit if variables that should go unspecified
> were written out, but not given a value? Maybe I'm misunderstanding
> the point of explicit values though.

I made it *unspecified* in 59ee837d8b, given this service config doesn't
yet use 'define-configuration' that would have allowed for a proper
maybe-value.

Tested to work on a X200 and pushed!

Closing, at last.

Thanks,

Maxim

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Maxim Cournoyer]

Hi Attila,

Attila Lendvai  writes:

[...]

> also, seems like it didn't register in this discussion, so i press it
> once again: if the default/unspecified value is a symbol (any symbol),
> then those configuration fields, whose type is set to be of symbol,
> will not error when they are left unspecified. (see the
> FIELD-SANITIZER: it simply does a (IF (PRED VALUE) ...) check, which
> doesn't fail because 'UNSET satisfies SYMBOL?). i should have added a
> unit test for this...

OK, I've reread this, and it is indeed a risk, that 'unset could leak in
the case of a serializable configuration making use of a maybe-value
field of type maybe-symbol.  I've added the unit test suggested as
97cb43e732a38758c95b7caf3963507188d011cf (currently marked as 'expected
to fail').  Luckily no current service uses that.

I think the tension between serializable vs non-serializable unspecified
values comes from the two kind of usages of define-configuration: one is
to generate config files, in which unspecified means "nothing", and
shouldn't touch disk, while in the case it's used as a more general data
type (define-configuration/no-serialization), there is value in being
able to lower that data type on the build/target so that things can be
lazily computed where needed, without loss of information.

We should add one more unit test to exercise this last usage in action
(currently only jami-service-type makes use of that, but I have an
upcoming Xvnc service that benefits from that as well).

Thanks,

Maxim

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Maxim Cournoyer]

Hi Attila,

Attila Lendvai  writes:

>> i'm obviously not aware of the entire complexity here, othrwise
>> there wouldn't have remained a bug... but regardless of the actual
>> API/value used, i don't see how any of this could work without the
>> service code explicitly checking for the unspecified value for
>> fields that have a maybe type (i.e. whose type allows the value to
>> be unspecified). i think using a symbol instead of unspecified only
>> pushes the appearance of the symptoms farther away both in time and
>> space (otherwise there should have been a trivial fix to this
>> without changing unspecified back to 'unset).
>
>
> sorry, i was wrong/slow here^.
>
> i think i finally understand what the original issue was that triggered the 
> rollback:
>
> the *UNSPECIFIED* value cannot get through the GExp
> serialize/deserialize operation between the host/builder (or how do we
> call it?) and Shepherd. the checks in the service code that handle the
> unspecified field values only happen when Shepeherd is executing the
> deserialized GExp's.

That's the issue, yes!  the *unspecified* value cannot cross the
host/build border, which forces someone to pre-compute all things before
serialization happens, which is inconvenient at best in some scenarios I
hinted at (a recent one is defining inetd-style services, which
endpoints need to be computed on the target (inside the service gexp)).

> the fix i would propose is to smarten up GExp serialization to handle
> whichever value we use as the marker, be it 1) *UNSPECIFIED*, or 2)
> Nothing from srfi-189, or 3) a record instance that we
> define/instantiate ourselves.

That's what I first attempted, without success.  That *unspecified*
expands to some random object on every usage seems meant to discourage
its usage as a specific value (its name, too!)

> i don't recommend 3). we should rather use srfi-189 then, because it
> sandardizes widely known concepts

srfi-189 sounds fancy, but how would it be better than the 'unset
symbol?  Could you please restate the problems faced when using a
symbol?  Would it be lowerable into Gexp, unlike *unspecified*?  To me,
in Guile this means having a readily implemented reader syntax.

> so, would you accept a patch that implements 1) or 2) ?

As I mentioned earlier, the specific value used for a maybe value is an
implementation detail, or should be made one, in my opinion.  So it
doesn't matter to me, as long as it makes writing services convenient
and passes all the tests (I recently augmented the jami-service-type
test which such a case to avoid any regressions).

Thanks,

Maxim

bug#57046: Spanish documentation uses exclusive language

[bokr]

Hi,

tl;dr:

IMO this whole language neutering project, whose goal UIAM is
purportedly to exclude exclusion, is self-contradictory.

I.e., it excludes those who are used to natural language as they
have learned it (including words to charm or insult or play with),
and are not distracted by gender inflections in documentation.
If they opine about sex, they'll likely say "Vive la différence!"

If some people really need a neutered documentation language, fine:
Invent a sexlessperanto DSL and make that a translation target
which the sensitive can opt to read.

IMO it's a waste of time to contort normal natural language expressions
and idioms into eunuch grotesqueries. Besides, those annoyed by the nonsense
will be tempted to game the wording to tease the teasable anyway.

If you find yourself allergic to Mediterranean diets (word or food)
I feel sorry for you. But that doesn't give you a right to control
the menu anywhere other than in your kitchen.

Statistically Mediterranean diets are healthy, and healthy people can
digest sometimes spicy food, or words, and know how to spit out
the occasional chicken bone splinter. That's why we chew.
Didn't your mother teach you not to swallow things whole?
Chew words from an iffy dish well :)

My 2¢, sorry :)

On +2022-08-09 15:46:17 +0200, Ludovic Courtès wrote:
> Hola,
> 
> "pelzflorian (Florian Pelz)"  skribis:
> 
> > * the main Spanish translation po/guix/es.po uses usuario
> >
> > * the French translation switches between “utilisateur·rices”,
> >   “utilisatrices et utilisateurs” and more often masculine “utilisateurs”
> >
> > * the Portuguese, Russian, German translation use masculine (although at
> >   least for German I use feminine in some examples)
> >
> > * German word for users is masculine Benutzer and feminine is
> >   Benutzerinnen; there is a psychology study that Benutzer*innen is
> >   perceived feminine while listing both masculine and feminine Benutzer
> >   und Benutzerinnen is perceived as including men and women (a different
> >   language and I might give too much weight to one scientific study)
> >   
> > 
> 
> Just like for French, my suggestion would be to use a mixture of several
> techniques to achieve gender neutrality, probably in this order:
> 
>   • Using gender-neutral words—e.g., “personas” or “quién” rather than
> “usuarios”.
> 
>   • Talking to the user: “puedes hacer …” rather than “usuarios pueden
> hacer …”.
> 
>   • Using the -e suffix, which has the advantage of being concise and
> readable, but potentially off-putting (at least today).
> 
>   • Using repetitions, “usuarias y usuarios”.
> 
> Latin languages (among others) are problematic but techniques like these
> can get us a long way, and by mixing them we can avoid making the text
> hard to read.
> 
> Ludo’.
> 
--
Regards,
Bengt  Richter

bug#57068: Resizing mcron job in vm-image.tmpl interferes with settings

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hello!
>
> Commit 945ad48cd8029fa77a643e00c7fd350e98cacca0 added an mcron job to
> ‘vm-image.tmpl’ that resets screen size every second.  I’m don’t fully
> understand the problem this was addressing, but it has two drawbacks:

The vm-image.tmpl is the template we use for our graphical Guix demo
QEMU image that can be downloaded from our site
(https://guix.gnu.org/en/download/ ->
https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2).

This commit was made to allow SPICE dynamic resizing to work, as
mentioned in a comment part of this commit.  XFCE lacks support for it,
as also mentioned in the comment
(https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/142), which means
a new user downloading the image and running it in a SPICE-capable
viewer such as virt-manager or gnome-boxes will be dismayed that it
doesn't resize as they may have come to expect from other modern
distributions.

>   1. Kicking in every second is inefficient.

5% on my machine, as mentioned in the commit message.  The trade is
still on the winning side for me (dynamic resizing is a big upgrade for
the user experience in my book).

>   2. Resetting the screen size prevents users from changing it.  For
>  example, if I run:
>
>$(guix system vm gnu/system/examples/vm-image.tmpl) -m 1024
>
> then go to the Xfce menu, Settings -> Display, and change the screen
> size, I have it immediately reset back to the default value.

OK.  I didn't know this could be workable use case with the stock QEMU
viewer when playing with graphical VMs.

> Should we remove this workaround, possibly finding another one?

I think we should use a desktop environment that is better maintained,
and which works well with SPICE, without hacks, given the improvements
to the user experience it provides, and given it's important that a
first user encounter with Guix be smooth and shiny.  GNOME could do it,
at the cost of a bigger image size.

There are other, perhaps worst issues with XFCE, which is that the
keyboard layout switcher doesn't work, and it didn't seem trivial to fix
when I looked at it.

What do you think?

Thanks,

Maxim

bug#57067: Missing Xfce icons

[宋文武 via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> In current ‘master’ (ca. 6db3b34d7203639ef4286c237a6e536259f92352), in a
> VM created with:
>
>   guix system vm gnu/system/examples/vm-image.tmpl
>
> Xfce is lacking a few icons in window decorations and in the bar at the top:
>

Fixed in commit 02b69362cb5922e3e2579b120a12afcc6167a46e now.

GTK+3 (and 4) requires the Adwaita icon theme is always available.
Maybe we can make gtk+ depends and hardcode the path to
adwaita-icon-theme to avoid install it into the profile.

Thank you!

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Howdy,
>
> Maxim Cournoyer  skribis:

[...]

>> I think mostly because few services make use of define-configuration.
>> While attempting to write a new VNC service, it quickly became a visible
>> annoyance:
>>
>> (define-configuration/no-serialization xvnc-configuration
>
> [...]
>
>>   (port
>>maybe-port
>>"The port on which to listen for connections from viewers.  When left
>> unspecified, it defaults to 5900 plus the display number.")
>
> [...]
>
>> (define (xvnc-shepherd-service config)
>>   "Return a  for Xvnc with CONFIG."
>>   ;; XXX: Ensure all the *unspecified* values are handled outside of gexps, 
>> as
>>   ;; they are not valid gexp input (they are not self-quoting/serializable).
>>   ;; This would otherwise cause problem during 'guix deploy'.
>>   (let* ((display-number (xvnc-configuration-display-number config))
>>  (port (if (unspecified? (xvnc-configuration-port config))
>>#f
>>(xvnc-configuration-port config)))
>
> OK, I see.  I guess most of the time, we just call
> ‘serialize-xyz-configuration’, which automatically handles *unspecified*
> values.  In this case, ‘port’ is treated specially and instead passed as
> a command-line argument.

Yes, and that provides much welcome flexibility, as records are
serializable (as vectors) so long as the values they contain also are.

> Other ways to address that come to mind include: adding ‘port’ to the
> config file instead of on the command line (if possible), or doing:
>
>   (serialize-configuration config
>(find (lambda (field)
>(eq? (configuration-field-name field)
> 'port))
>  xvnc-configuration-fields))
>
> That’s a mouthful but maybe it could be abstracted.  It does sound less
> convenient though.

Xvnc takes no config switch, and I agree the above is not
intuitive/great.  It also wouldn't fix the use case of places it is more
convenient to have the maybe value expanded into the gexp and dealt with
there, such as used in the jami-service-type and in my previous example
making use of a inetd style service, where shepherd-side only bindings
such as endpoint makes it convenient to place the ports logic inside the
service gexp.

> That said, whether it’s ‘unspecified?’ or something else, you have to
> have a check in place, right?  With the new interface it becomes:
>
>  (if (eq? port 'unset) #f port)
>
> Or you can provide an actual default value (an integer in this case),
> but that’s possible whether or not *unspecified* is the default value.

To me, the main use of maybe values is to allow for the daemon to use
its own default when no value is specified.  A maybe value with a
default value makes little sense to me, so we should move toward
eliminating that style and support for it from define-configuration, in
my opinion.  Things would be a bit easier to reason with then.

As a baby step toward making 'unset a properly hidden implementation
detail, I'd suggest the attached patch, which adds a means to check if a
value was set.

>From ac84f836a5a6c451465a879521a306b6fbcbed50 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer 
Date: Fri, 5 Aug 2022 15:03:55 -0400
Subject: [PATCH] services: configuration: Add a 'maybe-value-set?' procedure.

* gnu/services/configuration.scm (maybe-value-set?): New procedure.
* doc/guix.texi (Complex Configurations): Document it.  Remove comment showing
usage of 'maybe-string' with a default value, which doesn't make sense.
---
 doc/guix.texi  | 7 ++-
 gnu/services/configuration.scm | 5 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index eb3a1a4eb5..ccdd01f321 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -38998,7 +38998,7 @@ to be a string, or left unspecified.
   (name
;; If set to a string, the `serialize-string' procedure will be used
;; to serialize the string.  Otherwise this field is not serialized.
-   maybe-string; equivalent to (maybe-string *unspecified*)
+   maybe-string
"The name of this module."))
 @end lisp
 
@@ -39029,6 +39029,11 @@ whether its value is set or not.
 @end lisp
 @end deffn
 
+@deffn (Scheme Procedure) maybe-value-set? @var{value}
+Predicate to check whether a user explicitly specified the value of a
+maybe field.
+@end deffn
+
 @deffn {Scheme Procedure} serialize-configuration @var{configuration} @
 @var{fields}
 Return a G-expression that contains the values corresponding to the
diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm
index 3007e8de35..b41b4d2e62 100644
--- a/gnu/services/configuration.scm
+++ b/gnu/services/configuration.scm
@@ -57,6 +57,7 @@ (define-module (gnu services configuration)
 serialize-configuration
 define-maybe
 define-maybe/no-serialization
+maybe-value-set?
 

bug#57083: Jekyll is unusable

[Ségolène Métais]

Hi, here is the issue with Jekyll :

sego@pluto ~$ guix describe
Génération 14508 août 2022 14:09:22(actuelle)
  guix ec6499a
URL du dépôt : https://git.savannah.gnu.org/git/guix.git
branche : master
commit : ec6499aad231b8a5991f38c1ec982be4b3598837

sego@pluto ~/job/site/www$ guix shell jekyll ruby -- jekyll new testdir
--force
Running bundle install in /home/sego/job/site/www/testdir...
  Bundler: --- ERROR REPORT TEMPLATE
---
  Bundler:
  Bundler: ```
  Bundler: Errno::EROFS: Read-only file system @ rb_sysopen -
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/gems/3.1.0/bundler.lock
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/process_lock.rb:9:in
`initialize'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/process_lock.rb:9:in
`open'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/process_lock.rb:9:in
`lock'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/installer.rb:71:in
`run'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/installer.rb:23:in
`install'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/cli/install.rb:62:in
`run'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/cli.rb:255:in
`block in install'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/settings.rb:131:in
`temporary'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/cli.rb:254:in
`install'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/command.rb:27:in
`run'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in
`invoke_command'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor.rb:392:in
`dispatch'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/cli.rb:31:in
`dispatch'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/base.rb:485:in
`start'
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/cli.rb:25:in
`start'
  Bundler:
/gnu/store/30llcsghdk6ycdr2738shysnj473hfnj-ruby-2.7.4/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/libexec/bundle:46:in
`block in '
  Bundler:
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/3.1.0/bundler/friendly_errors.rb:103:in
`with_friendly_errors'
  Bundler:
/gnu/store/30llcsghdk6ycdr2738shysnj473hfnj-ruby-2.7.4/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/libexec/bundle:34:in
`'
  Bundler: ```
  Bundler:
  Bundler: ## Environment
  Bundler:
  Bundler: ```
  Bundler: Bundler 2.3.7
  Bundler: Platforms ruby, x86_64-linux
  Bundler: Ruby 3.1.1p18 (2022-02-18 revision
53f5fc4236a754ddf94b20dbb70ab63bd5109b18) [x86_64-linux]
  Bundler: Full Path
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/bin/ruby
  Bundler: Config Dir
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/etc
  Bundler: RubyGems 3.3.7
  Bundler: Gem Home
/gnu/store/vi3wmci309sx5xlsbzbxb17hnn3r3wd9-ruby-3.1.1/lib/ruby/gems/3.1.0
  Bundler: Gem Path

bug#56556:

[Wicki Gabriel (wicg)]

I have the same issue. Tested in German language -- it works just fine with the 
full-fledged LaTeX environment.

bug#57071: Xscreensaver not working since latest patch

[Rick Huijzer]

Hi,

The latest xscreensaver patch  rendered
xscreensaver unusable on my systems. When I try to unlock my screen I am
greeted with the message 'xscreensaver: don't login as root', even though I
don't invoke it as root.


$xscreensaver-command -lock
Aug  9 08:45:22 localhost shepherd[1]: [slim] xscreensaver-gfx: 08:45:22:
1: running as root: not launching hacks.
Aug  9 09:10:29 localhost shepherd[1]: [slim] xscreensaver-command: locking
Aug  9 09:10:32 localhost shepherd[1]: [slim] xscreensaver-gfx: 09:10:32:
0: running as root: not launching hacks.

When I remove the
(screen-locker-service xscreensaver)
I run into all kinds of set-uid problems.

I will happily provide more information if needed.

-- 
Met vriendelijke groet,

Rick Huijzer

bug#57093: 'guix style --whole-file' hangs indefinitely if parenthesis is unmatched

[Mohammed AMAR-BENSABER]

Hi,

guix style --whole-file package.scm hangs indefinitely if parenthesis is 
unmatched. Relevant commit a15542d26df42dabdb5e2f76d150ae200230c3b0.

Here is an example package definition with missing a parenthesis. 

(define-public vim-asyncrun
  (package
(name "vim-asyncrun")
(version "2.8.6")
(source (origin
  (method git-fetch)
  (uri (git-reference
 (url "https://github.com/skywind3000/asyncrun.vim;)
 (commit version)))
  (file-name (git-file-name name version))
  (sha256
   (base32
"11zcw0sll6qg6ha0rr6n1cw5v73azvf7ycwn9lgiwa5cj7rrqjf4"
(build-system copy-build-system)
(arguments
 '(#:install-plan
   '(("plugin" "share/vim/vimfiles/")
 ("doc/" "share/vim/vimfiles/doc" #:include ("asyncrun.txt")
(home-page "https://github.com/skywind3000/asyncrun.vim;)
(synopsis "Run Async Shell Commands in Vim")
(description "This plugin takes the advantage of new APIs in Vim 8 (and
NeoVim) to enable you to run shell commands in background and read output in 
the
quickfix window in realtime.")
(license license:expat))

-- 
Mohammed 'Renken' AMAR-BENSABER

signature.asc
Description: This is a digitally signed message part.

bug#55657: libgccjit is unusable

[Andrew Whatson]

John Kehayias wrote:
>
> As for the original issue here, I guess the LIBRARY_PATH and ld shadowing is 
> the workaround. I don't know if that is something that can/should be 
> incorporated into the libgccjit package definition or should just be handled 
> by any package using it. Currently, that will just be emacs anyway and 
> hopefully the discussion here is useful to anyone trying to use libgccjit.

This might be possible by adding LIBRARY_PATH to native-search-paths
in the libgccjit package definition?

> Thanks again Lily and Andrew for your work here!

Thanks John & Lily for persisting with getting this submitted, I'm
very grateful for your efforts.

Cheers,
Andrew

bug#57095: another "inappropriate ioctl" bug :)

[Csepp]

```
./pre-inst-env guix import pypi -r linode-cli | tee -a 
gnu/packages/python-xyz.scm

...
In guix/build/syscalls.scm:
  2284:35  1 (_)
   2273:8  0 (terminal-window-size _)

guix/build/syscalls.scm:2273:8: In procedure terminal-window-size:
In procedure terminal-window-size: Inappropriate ioctl for device
```

I assume the progress bar code does not gracefully handle the very
common case when stdout is not a terminal.

Good thing I'm in a local checkout so I can just make it return some
constant.

bug#56866: [Shepherd] inetd connections not correctly counted?

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> We recently experienced a bug on berlin.guix where we’d be locked out of
> SSH access because shepherd (0.9.1) would say that the maximum
> connection number on the sshd inetd service had been reached.

On berlin.guix, which is getting hammered, we see things like this:

--8<---cut here---start->8---
Aug  9 23:32:13 localhost shepherd[1]: Service sshd-4183 (PID 55570) exited 
with 255.
Aug  9 23:32:13 localhost shepherd[1]: Service sshd-4183 has been disabled.
Aug  9 23:32:13 localhost shepherd[1]: Transient service sshd-4183 terminated, 
now unregistered.
Aug  9 23:32:15 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
X.X.X.104:39528.
Aug  9 23:32:15 localhost shepherd[1]: Service sshd-4189 has been started.
Aug  9 23:32:20 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
X.X.X.104:40378.
Aug  9 23:32:21 localhost shepherd[1]: Service sshd-4190 has been started.
Aug  9 23:32:25 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
X.X.X.104:41190.
Aug  9 23:32:25 localhost sshd[55635]: error: kex_exchange_identification: 
Connection closed by remote host
Aug  9 23:32:25 localhost sshd[55635]: Connection closed by X.X.X.167 port 50938
Aug  9 23:32:26 localhost shepherd[1]: Service sshd-4191 has been started.
Aug  9 23:32:26 localhost shepherd[1]: 7 connections still in use after 
sshd-4185 termination.
Aug  9 23:32:26 localhost shepherd[1]: Service sshd-4185 (PID 55635) exited 
with 255.
Aug  9 23:32:26 localhost shepherd[1]: Service sshd-4185 has been disabled.
Aug  9 23:32:26 localhost shepherd[1]: Transient service sshd-4185 terminated, 
now unregistered.
Aug  9 23:32:30 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
X.X.X.104:41918.
Aug  9 23:32:31 localhost shepherd[1]: Service sshd-4192 has been started.
Aug  9 23:32:34 localhost sshd[55632]: error: kex_exchange_identification: 
Connection closed by remote host
Aug  9 23:32:34 localhost sshd[55632]: Connection closed by X.X.X.167 port 50966
Aug  9 23:32:34 localhost shepherd[1]: 7 connections still in use after 
sshd-4184 termination.
Aug  9 23:32:34 localhost shepherd[1]: Service sshd-4184 (PID 55632) exited 
with 255.
Aug  9 23:32:34 localhost shepherd[1]: Service sshd-4184 has been disabled.
Aug  9 23:32:34 localhost shepherd[1]: Transient service sshd-4184 terminated, 
now unregistered.
Aug  9 23:32:35 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
X.X.X.104:42736.
Aug  9 23:32:36 localhost shepherd[1]: Service sshd-4193 has been started.
Aug  9 23:32:40 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
X.X.X.104:43492.
Aug  9 23:32:41 localhost shepherd[1]: Service sshd-4194 has been started.
Aug  9 23:32:44 localhost sshd[56155]: error: kex_exchange_identification: 
Connection closed by remote host
Aug  9 23:32:44 localhost sshd[56155]: Connection closed by X.X.X.80 port 52450
Aug  9 23:32:44 localhost shepherd[1]: 8 connections still in use after 
sshd-4186 termination.
Aug  9 23:32:44 localhost shepherd[1]: Service sshd-4186 (PID 56155) exited 
with 255.
Aug  9 23:32:44 localhost shepherd[1]: Service sshd-4186 has been disabled.
Aug  9 23:32:44 localhost shepherd[1]: Transient service sshd-4186 terminated, 
now unregistered.
Aug  9 23:32:45 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
X.X.X.104:44194.
Aug  9 23:32:46 localhost shepherd[1]: Service sshd-4195 has been started.
Aug  9 23:32:53 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
X.X.X.104:45170.
Aug  9 23:32:53 localhost shepherd[1]: Service sshd-4196 has been started.
Aug  9 23:32:56 localhost ntpd[1706]: Soliciting pool server X.X.X.107
Aug  9 23:32:58 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
X.X.X.104:45846.
Aug  9 23:32:58 localhost shepherd[1]: Service sshd-4197 has been started.
Aug  9 23:33:03 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
X.X.X.104:46514.
Aug  9 23:33:03 localhost shepherd[1]: Service sshd-4198 has been started.
Aug  9 23:33:08 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
X.X.X.104:47230.
Aug  9 23:33:08 localhost shepherd[1]: Service sshd-4199 has been started.
Aug  9 23:33:13 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
X.X.X.104:47940.
Aug  9 23:33:13 localhost shepherd[1]: Service sshd-4200 has been started.
Aug  9 23:33:17 localhost sshd[56715]: error: kex_exchange_identification: 
client sent invalid protocol identifier ""
Aug  9 23:33:17 localhost sshd[56715]: banner exchange: Connection from 
X.X.X.104 port 37546: invalid format
Aug  9 23:33:17 localhost shepherd[1]: 13 connections still in use after 
sshd-4188 termination.
Aug  9 23:33:17 localhost shepherd[1]: Service sshd-4188 (PID 56715) exited 
with 255.
Aug  9 23:33:17 localhost shepherd[1]: Service sshd-4188 has been disabled.
Aug  9 23:33:17 localhost shepherd[1]: Transient service sshd-4188 terminated, 
now unregistered.
Aug  9 23:33:18 

bug#57071: Xscreensaver not working since latest patch

[Ludovic Courtès]

Hi Rick,

Rick Huijzer  skribis:

> The latest xscreensaver patch  rendered
> xscreensaver unusable on my systems. When I try to unlock my screen I am
> greeted with the message 'xscreensaver: don't login as root', even though I
> don't invoke it as root.
>
>
> $xscreensaver-command -lock
> Aug  9 08:45:22 localhost shepherd[1]: [slim] xscreensaver-gfx: 08:45:22:
> 1: running as root: not launching hacks.
> Aug  9 09:10:29 localhost shepherd[1]: [slim] xscreensaver-command: locking
> Aug  9 09:10:32 localhost shepherd[1]: [slim] xscreensaver-gfx: 09:10:32:
> 0: running as root: not launching hacks.
>
> When I remove the
> (screen-locker-service xscreensaver)
> I run into all kinds of set-uid problems.

Sorry about that, I built it during review but did not actually run it.

One effect of ‘screen-locker-service’ is to make the program setuid-root
so that it can authenticate users.  It would seem that something changed
in xscreensaver in that area; quoth ‘driver/subprocs.c’:

--8<---cut here---start->8---
  if (getuid() == (uid_t) 0 || geteuid() == (uid_t) 0)
/* Prior to XScreenSaver 6, if running as root, we would change the
   effective uid to the user "nobody" or "daemon" or "noaccess",
   but even that was just encouraging bad behavior.  Don't log in
   as root. */
{
  fprintf (stderr, "%s: %d: running as root: not launching hacks.\n",
   blurb(), ssi->number);
  screenhack_obituary (ssi, "", "XScreenSaver: Don't log in as root.");
  goto DONE;
}
--8<---cut here---end--->8---

OTOH the ‘disavow_privileges’ function is supposed to drop root
privileges early on.

So I’m not sure how it’s supposed to be run.  R0man, ideas?

Thanks,
Ludo’.

bug#57091: Git authentication reports subkey fingerprints

[Maxime Devos]

On 09-08-2022 23:07, Ludovic Courtès wrote:

Hello,

As Tobias explains at
  and
as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
git-authenticate) machinery reports the fingerprint of subkeys on
signatures (when subkeys are used) rather than the fingerprint of
primary keys.

This should be changed to report primary keys, at least optionally.


Why should it be changed? IIUC .guix-authorizations and (guix ...) care 
about the key that things were signed with, not necessarily the primary 
key, so it seems to me that it needs to report the subkey fingerprint, 
not the fingerprint of the primary key it belongs to, as the primary key 
is irrelevant to them IIUC.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57077: guix-jupyter fails a test

[Ludovic Courtès]

Hi!

Andreas Enge  skribis:

> guix-jupyter currently fails to build with the error message below. While I
> noticed it when updating python-sympy, the problem was already present
> before.

It looks like the Jupyter protocol changed, probably in
d54b8754fdba52d89aafaaf80b6c8e89bcea92bd, which was merged with the
latest ‘staging’.

I’ll take a look if nobody beats me at it…

Ludo’.

bug#57090: [BUG] Default Notation for chmod in guix style?

[Ludovic Courtès]

Hi,

"("  skribis:

> On Tue Aug 9, 2022 at 9:59 PM BST, Maxime Devos wrote:
>> 'chmod' is not mentioned anywhere in (guix scripts style), so I'd think 
>> it's just an oversight. The authority on the matter would be Ludovic 
>> Courtès 
>
> Is it possible that (guix read-print) stores octal numbers directly as
> Scheme numbers, with no way to distinguish them from decimal numbers,
> which means when they are printed they are just treated as base10? I
> poked around a bit in the module but couldn't find the code for number
> reading.

Indeed, the reader is basically a wrapper around ‘read’.  It preserves
comments and vertical space, but it doesn’t attempt to preserve the
style of numbers (base, etc.), strings (whether \n & co. are escaped or
literal), and so on.  I think that’d be a bit too much honestly.

Now, we could tweak the pretty printer so that it recognizes patterns
where numbers or strings should be printed in a certain way.

Help welcome! :-)

Ludo’.

bug#57090: [BUG] Default Notation for chmod in guix style?

[paren--- via Bug reports for GNU Guix]

On Tue Aug 9, 2022 at 10:01 PM BST, Csepp wrote:
> Seems to be a Scheme limitation:
>
> ```
> scheme@(guile-user)> '(#o10)
> $1 = (8)
> ```

`guix style` uses a completely seperate reader, defined
in (guix read-print), so even though it's possible it has
the same limitation, we could easily modify it to support
octal/hexadecimal/binary numbers.

-- (

bug#57091: Git authentication reports subkey fingerprints

[Ludovic Courtès]

Hello,

As Tobias explains at
 and
as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
git-authenticate) machinery reports the fingerprint of subkeys on
signatures (when subkeys are used) rather than the fingerprint of
primary keys.

This should be changed to report primary keys, at least optionally.

Ludo’.

bug#57090: [BUG] Default Notation for chmod in guix style?

[Csepp]

Christopher Rodriguez  writes:

> [[PGP Signed Part:Undecided]]
>
> Hello,
>
> I've noticed that, when I explicitly declare absolute permissions in
> octal during a (chmod …) in my package definitions and then run guix
> style, it converts them to decimal instead.
>
> Is this intended? I've gotten feedback and agree that octal (#o755) is
> much clearer to read than decimal (493), simply because I'm used to the
> actual unix chmod tool and its conventions.

Seems to be a Scheme limitation:

```
scheme@(guile-user)> '(#o10)
$1 = (8)
```

bug#57090: [BUG] Default Notation for chmod in guix style?

[paren--- via Bug reports for GNU Guix]

On Tue Aug 9, 2022 at 9:59 PM BST, Maxime Devos wrote:
> 'chmod' is not mentioned anywhere in (guix scripts style), so I'd think 
> it's just an oversight. The authority on the matter would be Ludovic 
> Courtès 

Is it possible that (guix read-print) stores octal numbers directly as
Scheme numbers, with no way to distinguish them from decimal numbers,
which means when they are printed they are just treated as base10? I
poked around a bit in the module but couldn't find the code for number
reading.

-- (

bug#57090: [BUG] Default Notation for chmod in guix style?

[Maxime Devos]

Note: No need for [BUG] prefixes -- they are prefixed automatically by 
bug#N and the bug tracker is either for bugs or patches, and the 
latter has the [PATCH ...] convention. No harm though.


On 09-08-2022 22:47, Christopher Rodriguez wrote:

Hello,

I've noticed that, when I explicitly declare absolute permissions in
octal during a (chmod …) in my package definitions and then run guix
style, it converts them to decimal instead.

Is this intended? I've gotten feedback and agree that octal (#o755) is
much clearer to read than decimal (493), simply because I'm used to the
actual unix chmod tool and its conventions.

--

Christopher Rodriguez


'chmod' is not mentioned anywhere in (guix scripts style), so I'd think 
it's just an oversight. The authority on the matter would be Ludovic 
Courtès 


Disclaimer: I'm the one that wrote that feedback. Let's not double-count 
my non-existent 'votes'.


Greetings,
Maxime



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57090: [BUG] Default Notation for chmod in guix style?

[Christopher Rodriguez]

Hello,

I've noticed that, when I explicitly declare absolute permissions in
octal during a (chmod …) in my package definitions and then run guix
style, it converts them to decimal instead.

Is this intended? I've gotten feedback and agree that octal (#o755) is
much clearer to read than decimal (493), simply because I'm used to the
actual unix chmod tool and its conventions.

--

Christopher Rodriguez


signature.asc
Description: PGP signature

bug#57089: r-rmarkdown contains minified JavaScript

[paren--- via Bug reports for GNU Guix]

On Tue Aug 9, 2022 at 9:38 PM BST, Ricardo Wurmus wrote:
> It is not immediately obvious, where the corresponding source code could be
> found:

They seem to come from various NPM packages; looks like these ones:

* https://www.npmjs.com/package/bootstrap
* https://www.npmjs.com/package/highlightjs
* https://www.npmjs.com/package/jquery-ui
* https://www.npmjs.com/package/prettify
* https://www.npmjs.com/package/tocify

We could try to package them and then unvendor them from r-markdown,
but given the horrific state of JS packaging, we'd better expect a
tedious process.

-- (

bug#55657: libgccjit is unusable

[John Kehayias via Bug reports for GNU Guix]

Thanks for the new patchset Lily, very excited to have emacs with native 
compiliation in upstream Guix! (At the very least so I don't have to compile 
libgccjit and emacs)

For everyone following along at home, please see 
https://issues.guix.gnu.org/57086

As for the original issue here, I guess the LIBRARY_PATH and ld shadowing is 
the workaround. I don't know if that is something that can/should be 
incorporated into the libgccjit package definition or should just be handled by 
any package using it. Currently, that will just be emacs anyway and hopefully 
the discussion here is useful to anyone trying to use libgccjit.

Thanks again Lily and Andrew for your work here!

bug#57089: r-rmarkdown contains minified JavaScript

[Ricardo Wurmus]

r-rmarkdown contains a lot of minified JavaScript.  It is not
immediately obvious, where the corresponding source code could be found:

--8<---cut here---start->8---
rmarkdown/inst/rmd/ioslides/ioslides-13.5.1/js/prettify/prettify.js: ASCII 
text, with very long lines
rmarkdown/inst/rmd/ioslides/ioslides-13.5.1/js/prettify/lang-yaml.js: ASCII 
text, with very long lines
rmarkdown/inst/rmd/ioslides/ioslides-13.5.1/js/require-1.0.8.min.js: ASCII 
text, with very long lines
rmarkdown/inst/rmd/ioslides/ioslides-13.5.1/js/polyfills/history.min.js: 
exported SGML document, ASCII text, with very long lines, with no line 
terminators
rmarkdown/inst/rmd/ioslides/ioslides-13.5.1/js/polyfills/classList.min.js: 
ASCII text, with very long lines
rmarkdown/inst/rmd/ioslides/ioslides-13.5.1/js/polyfills/dataset.min.js: ASCII 
text, with very long lines
rmarkdown/inst/rmd/ioslides/ioslides-13.5.1/js/order.js: ASCII text, with very 
long lines
rmarkdown/inst/rmd/ioslides/ioslides-13.5.1/js/modernizr.custom.45394.js: HTML 
document, ASCII text, with very long lines
rmarkdown/inst/rmd/h/tocify/jquery.tocify.js: ASCII text, with very long lines
rmarkdown/inst/rmd/h/jqueryui/jquery-ui.min.js: ASCII text, with very long lines
rmarkdown/inst/rmd/h/jqueryui/jquery-ui.js: ASCII text, with very long lines
rmarkdown/inst/rmd/h/bootstrap/shim/respond.min.js: HTML document, ASCII text, 
with very long lines
rmarkdown/inst/rmd/h/bootstrap/shim/html5shiv.min.js: HTML document, ASCII 
text, with very long lines
rmarkdown/inst/rmd/h/bootstrap/js/bootstrap.min.js: ASCII text, with very long 
lines
rmarkdown/inst/rmd/h/highlightjs/highlight.js: UTF-8 Unicode text, with very 
long lines
--8<---cut here---end--->8---


-- 
Ricardo

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

Thank you Csepp/raingloom for speaking up.

Csepp  writes:
> Just a thought, but maybe it shouldn't be a group of men who decides
> what language is and is not inclusive

I believe we don’t disagree on what is / is not inclusive.

> and whether that's important.
> We've had some Outreachy interns, maybe some of them wouldn't mind being
> consulted on this.

There has been plenty of debate elsewhere; no need to bother; I guess
there won’t be consensus.  Yes, we could have a policy without
consensus.  Actually there may be a majority in favor of using verbose
speech that includes all.

Like "Once the patch is committed in the Guix repository[…].  Users can
obtain the new package definition simply by running guix pull"

"Una vez el parche se haya incorporado al repositorio de Guix[…].  Las
usuarias y los usuarios pueden obtener la nueva definición de paquete
ejecutando simplemente guix pull"

But doing that for every such sentence seems bothersome to read even in
cases when the sentence isn’t long already.  For French this is done but
not always.  Should it still be policy?  A strict or a lenient policy?

We could also just leave it to the individual Weblate translators until
an actual edit war occurs.  Even generic las usuarias had bothered
someone before on the Guix mailing lists but didn’t bother that much.
(I cannot find the link; it was a discussion involving Miguel Ángel
Arruga Vivas and that he uses “New Spanish”.)

Though the translation has become stale anyway and doesn’t fit the
English anymore; someone would need to update it.  Then generic las
usuarias stays until someone changes it on Weblate.

Should this bug be closed then?


> (Or we could do what Michael Warren Lucas does in his books: switch
> between female, male, and neutral.  I don't see how that would be
> exclusive.)

Well yeahh, yet another option. xD

Regards,
Florian

bug#53210: installer: referring to N-1 guix is problematic.

[Josselin Poiret via Bug reports for GNU Guix]

Hi Ludo,

Sorry for the delay, I was on holidays for the past few weeks.

Ludovic Courtès  writes:

> Hi Josselin & all,
>
> I ended up pushing the following patches:
>
>   fdafd40432 maint: Use a pretty version string in ISO and VM images.
>   95a03aa5c5 system: install: Always use 'current-guix'.
>   57f1892d36 gnu: guix: Default 'current-guix' is built using the current 
> channels.
>   64a070717c channels: Add 'repository->guix-channel'.
>   cf60a0a906 build-system/channel: Accept a channel or instance as the source.
>   5bce4c8242 build-system: Add 'channel-build-system'.

Great, thanks for adopting my code and fixing it up!

> Let me know if you have comments!
>
> Thanks,
> Ludo’.

-- 
Josselin Poiret

bug#55657: [PATCH 0/6] Add native compilation to Emacs

[Liliana Marie Prikler]

Hi Guix,

at long last the following patch set should enable native compilation
for both Emacs and emacs-build-system.  I tested emacs-dash and at the
very least native code is generated, though I haven't yet checked
whether it is also loaded.

As with any shiny new Emacs feature, please verify that the Emacs
portion of your manifests/home configurations build and report any
related errors *before* I push this and curse your configuration.

Cheers

Liliana Marie Prikler (6):
  gnu: Parameterize libgccjit.
  gnu: libgccjit: Build with bootstrapped gcc.
  gnu: libgccjit: Build multiple versions.
  gnu: emacs: Build with native compilation.
  guix: emacs-utils: Add emacs-compile-directory.
  build-system: emacs: Use native compilation.

 gnu/packages/emacs.scm| 64 ++-
 gnu/packages/gcc.scm  | 53 +
 guix/build/emacs-build-system.scm |  5 ++-
 guix/build/emacs-utils.scm| 26 +
 4 files changed, 128 insertions(+), 20 deletions(-)

-- 
2.37.0

bug#57046: Spanish documentation uses exclusive language

[Csepp]

"pelzflorian (Florian Pelz)"  writes:

> Hi Ludo.
>
> Ludovic Courtès  writes:
>>   • Using gender-neutral words—e.g., “personas” or “quién” rather than
>> “usuarios”.
>>
>>   • Talking to the user: “puedes hacer …” rather than “usuarios pueden
>> hacer …”.
>
> Agree, but when these don’t work,
>
>
>>   • Using the -e suffix, which has the advantage of being concise and
>> readable, but potentially off-putting (at least today).
>>
>>   • Using repetitions, “usuarias y usuarios”.
>
> It depends, but I think inclusiveness in technical manual sections is
> not important enough to justify such trade-offs (for the German
> translation that is).  Hrmm.  Of course I would comply if need be, but I
> do disagree.  (I have very little experience with Spanish though.)
>
> Regards,
> Florian

Just a thought, but maybe it shouldn't be a group of men who decides
what language is and is not inclusive and whether that's important.
We've had some Outreachy interns, maybe some of them wouldn't mind being
consulted on this.

Just my 2 fillérs.

(Or we could do what Michael Warren Lucas does in his books: switch
between female, male, and neutral.  I don't see how that would be
exclusive.)

bug#57052: elogind-service specifies a variable that's ignored by defualt

[Cairn via Bug reports for GNU Guix]

Would it not still be explicit if variables that should go unspecified were 
written out, but not given a value? Maybe I'm misunderstanding the point of 
explicit values though.

signature.asc
Description: OpenPGP digital signature

bug#57039: `make check' yields two failed tests.

[Ludovic Courtès]

Maxime Devos  skribis:

> On 09-08-2022 15:50, Ludovic Courtès wrote:
>>> +  (entry (tag "tag-for-first-news-entry")
>>> + (title (en "Old news.") (eo "Malnova?oj."))
>> The question mark here suggests you’re not running the tests with a
>> UTF-8 locale.
>>
>> Could you add, say, ‘glibc-locales’ to your environment, ensure
>> GUIX_LOCPATH points to it, and set LC_ALL=en_US.UTF-8 (or similar)?
>>
> Two comments:
>
> If tests require an UTF-8 locale, I think the tests (maybe in
> build-aux/test-driver.scm?) should check that an UTF-8 that an UTF-8
> locale is actually in use and otherwise bail out properly.
>
> It's not a file-name but rather the contents of the news file, so I
> would think we are just forgetting to pass some arguments like
> #:encoding "UTF-8" -- making the interpretation of the news file
> depend on the current locale doesn't seem good to me (it's encoding on
> stdout with "guix pull --news" is another matter).

Agreed, I came to the same conclusion:

  60e0aae89c channels: Consider news files as UTF-8-encoded by default.
  e1b8bace8c tests: git: Write files as UTF-8.

Should have done that long ago!

Ludo’.

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

Hi Ludo.

Ludovic Courtès  writes:
>   • Using gender-neutral words—e.g., “personas” or “quién” rather than
> “usuarios”.
>
>   • Talking to the user: “puedes hacer …” rather than “usuarios pueden
> hacer …”.

Agree, but when these don’t work,


>   • Using the -e suffix, which has the advantage of being concise and
> readable, but potentially off-putting (at least today).
>
>   • Using repetitions, “usuarias y usuarios”.

It depends, but I think inclusiveness in technical manual sections is
not important enough to justify such trade-offs (for the German
translation that is).  Hrmm.  Of course I would comply if need be, but I
do disagree.  (I have very little experience with Spanish though.)

Regards,
Florian

bug#57039: `make check' yields two failed tests.

[Maxime Devos]

On 09-08-2022 15:50, Ludovic Courtès wrote:


;;; (fail (package (name "python-foo") (version "1.0.0") (source (origin (method url-fetch) (uri (pypi-uri "foo" 
version)) (sha256 (base32 "03ygiww1c9fdgs998x4rqhxa73gq0r30rp0vq50q022wp1d6w0cz" (build-system python-build-system) (propagated-inputs 
(list python-wrong)) (home-page"http://example.com;) (synopsis "summary") (description "summary") (license 
license:lgpl2.0)) #f)
test-name: pypi->guix-package, wheels
location: /home/phf/src/guix/tests/pypi.scm:276
source:
+ (test-assert


I think I've seen this one fail before in the past, but 
non-deterministically, IIRC



Not sure about that one.  Does it still occur on current ‘master’?


It's a recent bug number and the submitter wrote they did "git checkout 
..." and "git pull", so it looks like this happened on a current 
master.  Looking at git.savannah.gnu.org there haven't been changes in 
this area, so I would think it's still effectively current master.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57039: `make check' yields two failed tests.

[Maxime Devos]

On 09-08-2022 15:50, Ludovic Courtès wrote:

+  (entry (tag "tag-for-first-news-entry")
+ (title (en "Old news.") (eo "Malnova?oj."))

The question mark here suggests you’re not running the tests with a
UTF-8 locale.

Could you add, say, ‘glibc-locales’ to your environment, ensure
GUIX_LOCPATH points to it, and set LC_ALL=en_US.UTF-8 (or similar)?


Two comments:

If tests require an UTF-8 locale, I think the tests (maybe in 
build-aux/test-driver.scm?) should check that an UTF-8 that an UTF-8 
locale is actually in use and otherwise bail out properly.


It's not a file-name but rather the contents of the news file, so I 
would think we are just forgetting to pass some arguments like 
#:encoding "UTF-8" -- making the interpretation of the news file depend 
on the current locale doesn't seem good to me (it's encoding on stdout 
with "guix pull --news" is another matter).


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57052: elogind-service specifies a variable that's ignored by defualt

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

>For the record, this was noticed and discussed more than a year ago, see
>Message-ID: <871rens9a2.fsf@nckx>.  It had fallen into the cracks

LOL.  I'm the one who asked Cairn to report this.  I didn't remember publicly 
reporting it, I only remembered noticing it and not fixing it, and didn't want 
it to get forgotten 'again'.  Sorry for the noise!

Strongly disagree that the current Guix behaviour makes any sense, let alone 
better!  That sounds like posthockholm rationalisation to me.  If people want 
opinionated variants, those can be written on top of a service that properly 
exposes upstream behaviour.


Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#54786: Installation tests are failing

[Mathieu Othacehe]

Closing as all the installation tests are now fixed.

Thanks to everyone involved :)

Mathieu

bug#57052: elogind-service specifies a variable that's ignored by defualt

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> Hi,
>
> Liliana Marie Prikler  writes:
>
>> Am Sonntag, dem 07.08.2022 um 23:29 + schrieb Cairn:
>>> "HandleLidSwitchExternalPower= is completely ignored by default (for
>>> backwards compatibility)"[1]
>>>
>>> I noticed (with help in IRC) that my laptop wasn't suspending on lid
>>> close when plugged in and charging, which I hadn't seen happen on
>>> other systems. I now know that I can set this by configuring the
>>> `elogind-service` parameter `handle-lid-switch-external-power`.
>>> Regardless, it seems like it should default to being unset rather
>>> than set/ignored, since that would heed the line I quoted above.
>> I think you're misreading that line.  What it states is not that
>> "HandleLidSwitchExternalPower" is ignored by default, but
>> "HandleLidSwitchExternalPower=" is ignored by default, i.e. there will
>> be no value unless one was provided (whichever semantics "no value" has
>> later on) is only confusingly explained later on.
>>
>> IMHO the Guix behaviour of always setting a value is the right one
>> (explicit is better than implicit after all).  As for the default
>> values, one might disagree as to which fits, but I don't think ignoring
>> lid switches while powered is harmful.
>
> It can be.  I have a Lenovo T430s with a partially discolored LCD from
> heat after I left it closed in a backpack for a couple hours, thinking
> it would have suspend (it was not).  That would not have happened with
> the value supposed to be default (which matches the behavior used on
> most other systems).
>
> So I'd favor having the default to suspend on any lid close.

For the record, this was noticed and discussed more than a year ago, see
Message-ID: <871rens9a2.fsf@nckx>.  It had fallen into the cracks, it
seems.

Maxim

bug#57052: elogind-service specifies a variable that's ignored by defualt

[Maxim Cournoyer]

Hi,

Liliana Marie Prikler  writes:

> Am Sonntag, dem 07.08.2022 um 23:29 + schrieb Cairn:
>> "HandleLidSwitchExternalPower= is completely ignored by default (for
>> backwards compatibility)"[1]
>> 
>> I noticed (with help in IRC) that my laptop wasn't suspending on lid
>> close when plugged in and charging, which I hadn't seen happen on
>> other systems. I now know that I can set this by configuring the
>> `elogind-service` parameter `handle-lid-switch-external-power`.
>> Regardless, it seems like it should default to being unset rather
>> than set/ignored, since that would heed the line I quoted above.
> I think you're misreading that line.  What it states is not that
> "HandleLidSwitchExternalPower" is ignored by default, but
> "HandleLidSwitchExternalPower=" is ignored by default, i.e. there will
> be no value unless one was provided (whichever semantics "no value" has
> later on) is only confusingly explained later on.
>
> IMHO the Guix behaviour of always setting a value is the right one
> (explicit is better than implicit after all).  As for the default
> values, one might disagree as to which fits, but I don't think ignoring
> lid switches while powered is harmful.

It can be.  I have a Lenovo T430s with a partially discolored LCD from
heat after I left it closed in a backpack for a couple hours, thinking
it would have suspend (it was not).  That would not have happened with
the value supposed to be default (which matches the behavior used on
most other systems).

So I'd favor having the default to suspend on any lid close.

Thanks,

Maxim

bug#57039: `make check' yields two failed tests.

[Ludovic Courtès]

Hi,

Pierre-Henry Fröhring  skribis:

> test-name: channel-news, one entry
> location: /home/phf/src/guix/tests/channels.scm:323
> source:
> + (test-assert
> +   "channel-news, one entry"

[...]

> +  (entry (tag "tag-for-first-news-entry")
> + (title (en "Old news.") (eo "Malnova?oj."))

The question mark here suggests you’re not running the tests with a
UTF-8 locale.

Could you add, say, ‘glibc-locales’ to your environment, ensure
GUIX_LOCPATH points to it, and set LC_ALL=en_US.UTF-8 (or similar)?

> ;;; (fail (package (name "python-foo") (version "1.0.0") (source (origin 
> (method url-fetch) (uri (pypi-uri "foo" version)) (sha256 (base32 
> "03ygiww1c9fdgs998x4rqhxa73gq0r30rp0vq50q022wp1d6w0cz" (build-system 
> python-build-system) (propagated-inputs (list python-wrong)) (home-page 
> "http://example.com;) (synopsis "summary") (description "summary") (license 
> license:lgpl2.0)) #f)
> test-name: pypi->guix-package, wheels
> location: /home/phf/src/guix/tests/pypi.scm:276
> source:
> + (test-assert
> +   "pypi->guix-package, wheels"
> +   (mock ((guix import utils)
> +  url-fetch
> +  (lambda (url file-name)
> +(match url
> +   ("https://example.com/foo-1.0.0.tar.gz;
> +(begin
> +  (mkdir-p "foo-1.0.0/foo.egg-info/")
> +  (with-output-to-file
> +"foo-1.0.0/foo.egg-info/requires.txt"
> +(lambda ()
> +  (display
> +"wrong data to make sure we're testing wheels 
> ")))
> +  (parameterize
> +((current-output-port (%make-void-port "rw+")))
> +(system* "tar" "czvf" file-name "foo-1.0.0/"))
> +  (delete-file-recursively "foo-1.0.0")
> +  (set! test-source-hash
> +(call-with-input-file file-name port-sha256
> +   ("https://example.com/foo-1.0.0-py2.py3-none-any.whl;
> +(begin
> +  (mkdir "foo-1.0.0.dist-info")
> +  (with-output-to-file
> +"foo-1.0.0.dist-info/METADATA"
> +(lambda () (display test-metadata)))
> +  (let ((zip-file (string-append file-name ".zip")))
> +(system*
> +  "zip"
> +  "-q"
> +  zip-file
> +  "foo-1.0.0.dist-info/METADATA")
> +(rename-file zip-file file-name))
> +  (delete-file-recursively "foo-1.0.0.dist-info")))
> +   (_ (error "Unexpected URL: " url)
> + (mock ((guix http-client)
> +http-fetch
> +(lambda (url . rest)
> +  (match url
> + ("https://pypi.org/pypi/foo/json;
> +  (values
> +(open-input-string test-json-1)
> +(string-length test-json-1)))
> + 
> ("https://example.com/foo-1.0.0-py2.py3-none-any.whl;
> +  #f)
> + (_ (error "Unexpected URL: " url)
> +   (invalidate-memoization! pypi->guix-package)
> +   (match (pypi->guix-package "foo")
> +  (('package
> +('name "python-foo")
> +('version "1.0.0")
> +('source
> + ('origin
> +  ('method 'url-fetch)
> +  ('uri ('pypi-uri "foo" 'version))
> +  ('sha256 ('base32 (? string? hash)
> +('build-system 'python-build-system)
> +('propagated-inputs
> + ('list 'python-bar 'python-baz))
> +('native-inputs ('list 'python-pytest))
> +('home-page "http://example.com;)
> +('synopsis "summary")
> +('description "summary")
> +('license 'license:lgpl2.0))
> +   (string=?
> + (bytevector->nix-base32-string test-source-hash)
> + hash))
> +  (x (pk 'fail x #f))
> actual-value: #f
> result: FAIL

Not sure about that one.  Does it still occur on current ‘master’?

See

on how to run only tests from ‘tests/pypi.scm’.

Thanks,
Ludo’.

bug#57046: Spanish documentation uses exclusive language

[Ludovic Courtès]

Hola,

"pelzflorian (Florian Pelz)"  skribis:

> * the main Spanish translation po/guix/es.po uses usuario
>
> * the French translation switches between “utilisateur·rices”,
>   “utilisatrices et utilisateurs” and more often masculine “utilisateurs”
>
> * the Portuguese, Russian, German translation use masculine (although at
>   least for German I use feminine in some examples)
>
> * German word for users is masculine Benutzer and feminine is
>   Benutzerinnen; there is a psychology study that Benutzer*innen is
>   perceived feminine while listing both masculine and feminine Benutzer
>   und Benutzerinnen is perceived as including men and women (a different
>   language and I might give too much weight to one scientific study)
>   
> 

Just like for French, my suggestion would be to use a mixture of several
techniques to achieve gender neutrality, probably in this order:

  • Using gender-neutral words—e.g., “personas” or “quién” rather than
“usuarios”.

  • Talking to the user: “puedes hacer …” rather than “usuarios pueden
hacer …”.

  • Using the -e suffix, which has the advantage of being concise and
readable, but potentially off-putting (at least today).

  • Using repetitions, “usuarias y usuarios”.

Latin languages (among others) are problematic but techniques like these
can get us a long way, and by mixing them we can avoid making the text
hard to read.

Ludo’.

bug#56680: go-1.16.15 build fails in check phase on powerpc64le

[Marcel van der Boom]

[Efraim Flashner]:

[...]
just removing the native-inputs field completely from 1.17 
should try to

make go-1.17 build with gccgo. Then try to build go@1.17.


That does indeed start a gccgo build and fails after a while with 
this:

( https://dpaste.org/3UwS2 has more details)


starting phase `build'
Building Go cmd/dist using 
/gnu/store/imii98jzv6jhgyk4k6mkagyhksjwn0rr-gccgo-10.3.0. (go1.14.6 
gccgo (GCC) 10.3.0 linux/ppc64le)
Building Go toolchain1 using 
/gnu/store/imii98jzv6jhgyk4k6mkagyhksjwn0rr-gccgo-10.3.0.

Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.

/tmp/guix-build-go-1.17.11.drv-0/source/src/internal/abi/abi.go:37:7: 
internal compiler error: '(*RegArgs).Dump': nil register for 
value: v13 = SelectN  [0] v12

bug#53210: installer: referring to N-1 guix is problematic.

[Ludovic Courtès]

Hi Josselin & all,

I ended up pushing the following patches:

  fdafd40432 maint: Use a pretty version string in ISO and VM images.
  95a03aa5c5 system: install: Always use 'current-guix'.
  57f1892d36 gnu: guix: Default 'current-guix' is built using the current 
channels.
  64a070717c channels: Add 'repository->guix-channel'.
  cf60a0a906 build-system/channel: Accept a channel or instance as the source.
  5bce4c8242 build-system: Add 'channel-build-system'.

The basics are similar to what you had posted.  It adds a useful default
for ‘current-guix’: a package built from the ‘guix’ channel as returned
by ‘guix describe’.  In turn, ‘%installation-os’ in (gnu system install)
is changed to use (current-guix) instead of the ‘guix’ package, meaning
that:

  guix system image gnu/system/install.scm

and:

  ./pre-inst-env guix system image gnu/system/install.scm

both produce an image that contains the current Guix.

That allows us to remove the second ‘update-guix-package.scm’ + ‘git
commit’ invocation in ‘make release’, which should make the whole
process faster.

Note that the default for installed systems remains the ‘guix’ package,
not (current-guix).  The main reason is that the “Computing derivation”
step when using (current-guix) is too high to do that by default.  We
could mitigate that by caching the result of that step more
systematically, but I think that can come later.

Let me know if you have comments!

Thanks,
Ludo’.

bug#57077: guix-jupyter fails a test

[Andreas Enge]

Hello,

guix-jupyter currently fails to build with the error message below. While I
noticed it when updating python-sympy, the problem was already present
before.

Andreas


test-name: execute_request
location: /tmp/guix-build-guix-jupyter-0.2.2.drv-0/source/tests/kernels.scm:100
source:
+ (test-equal
+   "execute_request"
+   42
+   (let ((request
+   (message
+ (header "execute_request" "luser" "12345")
+ (scm->json-string
+   (execute-request->json
+ (execute-request (code "40 + 2\n")))
+ (send-message %kernel request)
+ (let* ((replies
+  (unfold
+(cut > <> 4)
+(lambda (_) (read-message %kernel 1))
+#{1+}#
+0)))
+   (define (type-predicate type)
+ (lambda (message)
+   (string=? (message-type message) type)))
+   (and (every message? (pk 'replies replies))
+(match (filter (type-predicate "status") replies)
+   ((busy idle)
+(and (eq? 'busy
+  (kernel-status-execution-state
+(json->kernel-status (message-content busy
+ (eq? 'idle
+  (kernel-status-execution-state
+(json->kernel-status (message-content idle
+ (equal?
+   (message-parent-header busy)
+   (message-header request))
+ (equal?
+   (message-parent-header idle)
+   (message-header request)
+(let ((input (find (type-predicate "execute_input") replies)))
+  (equal?
+(message-parent-header input)
+(message-header request)))
+(let ((reply (find (type-predicate "execute_reply") replies)))
+  (equal?
+(message-parent-header reply)
+(message-header request)))
+(let ((result
+(find (type-predicate "execute_result") replies)))
+  (and (equal?
+ (message-parent-header result)
+ (message-header request))
+   (let* ((content
+(json-string->scm (message-content result)))
+  (data (assoc-ref content "data"))
+  (text (assoc-ref data "text/plain")))
+ (string->number text

;;; (replies (#< header: #< id: 
"5103841f-98e1ea45964e58d9ba214dc5_900_3" user: "username" session: 
"5103841f-98e1ea45964e58d9ba214dc5" date: "2022-08-09T13:21:24.436017Z" type: 
"kernel_info_reply" version: "5.3" sender: #f> parent-header: #< id: 
"7b136e32ddcbe2e226edffb116a4fca9" user: "luser" session: "12345" date: 
"2022-08-09T13:21:24.298532000" type: "kernel_info_request" version: "5.0" 
sender: #f> metadata: "{}" content: "{\"status\": \"ok\", \"protocol_version\": 
\"5.3\", \"implementation\": \"ipython\", \"implementation_version\": 
\"8.2.0\", \"language_info\": {\"name\": \"python\", \"version\": \"3.9.9\", 
\"mimetype\": \"text/x-python\", \"codemirror_mode\": {\"name\": \"ipython\", 
\"version\": 3}, \"pygments_lexer\": \"ipython3\", \"nbconvert_exporter\": 
\"python\", \"file_extension\": \".py\"}, \"banner\": \"Python 3.9.9 (main, Jan 
 1 1970, 00:00:01) \\nType 'copyright', 'credits' or 'license' for more 
information\\nIPython 8.2.0 -- An enhanced Interactive Python. Type '?' for 
help.\\n\", \"help_links\": [{\"text\": \"Python Reference\", \"url\": 
\"https://docs.python.org/3.9\"}, {\"text\": \"IPython Reference\", \"url\": 
\"https://ipython.org/documentation.html\"}, {\"text\": \"NumPy Reference\", 
\"url\": \"https://docs.scipy.org/doc/numpy/reference/\"}, {\"text\": \"SciPy 
Reference\", \"url\": \"https://docs.scipy.org/doc/scipy/reference/\"}, 
{\"text\": \"Matplotlib Reference\", \"url\": 
\"https://matplotlib.org/contents.html\"}, {\"text\": \"SymPy Reference\", 
\"url\": \"http://docs.sympy.org/latest/index.html\"}, {\"text\": \"pandas 
Reference\", \"url\": \"https://pandas.pydata.org/pandas-docs/stable/\"}]}; 
buffers: ()> #< header: #< id: 
"5103841f-98e1ea45964e58d9ba214dc5_900_4" user: "username" session: 
"5103841f-98e1ea45964e58d9ba214dc5" date: "2022-08-09T13:21:24.438407Z" type: 
"status" version: "5.3" sender: #vu8(107 101 114 110 101 108 46 100 53 55 102 
102 101 102 53 45 48 98 102 50 45 52 97 57 102 45 97 99 50 52 45 53 53 100 54 
97 97 100 102 53 56 52 97 46 115 116 97 116 117 115)> parent-header: #< 
id: "7b136e32ddcbe2e226edffb116a4fca9" user: "luser" session: "12345" date: 
"2022-08-09T13:21:24.298532000" type: "kernel_info_request" version: "5.0" 
sender: #f> metadata: "{}" content: "{\"execution_state\": \"idle\"}" buffers: 
()> #< header: #< id: 
"5103841f-98e1ea45964e58d9ba214dc5_900_5" user: "username" session: 

bug#57052: elogind-service specifies a variable that's ignored by defualt

[Cairn via Bug reports for GNU Guix]

(Resending this email, since I forgot to add the debugs.gnu.org address as a 
recipient)

> IMHO the Guix behaviour of always setting a value is the right one
> (explicit is better than implicit after all). As for the default
> values, one might disagree as to which fits, but I don't think ignoring
> lid switches while powered is harmful.

That's fair!

Well, if explicitly setting variables is the standard, then I suggest changing 
`handle-lid-switch-external-power` to the same value as `handle-lid-switch` 
("suspend"). I agree that the current setting isn't harmful, but this change 
would match the default, unconfigured behavior of `elogind`. It would also be 
more consistent with other distros' defaults from what I've experienced.

signature.asc
Description: OpenPGP digital signature

bug#57068: Resizing mcron job in vm-image.tmpl interferes with settings

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Commit 945ad48cd8029fa77a643e00c7fd350e98cacca0 added an mcron job to
> ‘vm-image.tmpl’ that resets screen size every second.  I’m don’t fully
> understand the problem this was addressing, but it has two drawbacks:
>
>   1. Kicking in every second is inefficient.
>
>   2. Resetting the screen size prevents users from changing it.  For
>  example, if I run:
>
>$(guix system vm gnu/system/examples/vm-image.tmpl) -m 1024
>
> then go to the Xfce menu, Settings -> Display, and change the screen
> size, I have it immediately reset back to the default value.

There’s a third problem that I initially thought was unrelated:

  3. The mcron job starts running before ‘xorg-server’ is up, and that
 can cause Xorg to fail to start.

Namely, if you run the command above, you’ll see that Xorg starts and
fails typically a few times in a row, until it eventually succeeds.  In
/var/log/messages, you can see that the ‘xorg-server’ process exits with
code 1 (without any indication of what went wrong AFAICS) and the
service gets respawned.

Now if you remove the mcron job and boot the VM, the ‘xorg-server’
service successfully starts.  It’s 100% reproducible for me.

I suppose the ‘xrandr’ command can kick in too early while Xorg is
initializing, causing it to exit.

Ludo’.

bug#57068: Resizing mcron job in vm-image.tmpl interferes with settings

[Ludovic Courtès]

Hello!

Commit 945ad48cd8029fa77a643e00c7fd350e98cacca0 added an mcron job to
‘vm-image.tmpl’ that resets screen size every second.  I’m don’t fully
understand the problem this was addressing, but it has two drawbacks:

  1. Kicking in every second is inefficient.

  2. Resetting the screen size prevents users from changing it.  For
 example, if I run:

   $(guix system vm gnu/system/examples/vm-image.tmpl) -m 1024

then go to the Xfce menu, Settings -> Display, and change the screen
size, I have it immediately reset back to the default value.

Should we remove this workaround, possibly finding another one?

Thanks,
Ludo’.

bug#57052: elogind-service specifies a variable that's ignored by defualt

[Liliana Marie Prikler]

Am Dienstag, dem 09.08.2022 um 03:52 +0200 schrieb b...@bokr.com:
> Hi Liliana,
> 
> On +2022-08-08 12:45:10 +0200, Liliana Marie Prikler wrote:
> > Am Sonntag, dem 07.08.2022 um 23:29 + schrieb Cairn:
> > > "HandleLidSwitchExternalPower= is completely ignored by default
> > > (for
> > > backwards compatibility)"[1]
> > > 
> > > I noticed (with help in IRC) that my laptop wasn't suspending on
> > > lid
> > > close when plugged in and charging, which I hadn't seen happen on
> > > other systems. I now know that I can set this by configuring the
> > > `elogind-service` parameter `handle-lid-switch-external-power`.
> > > Regardless, it seems like it should default to being unset rather
> > > than set/ignored, since that would heed the line I quoted above.
> > I think you're misreading that line.  What it states is not that
> > "HandleLidSwitchExternalPower" is ignored by default, but
> > "HandleLidSwitchExternalPower=" is ignored by default, i.e. there
> > will
> > be no value unless one was provided (whichever semantics "no value"
> > has
> > later on) is only confusingly explained later on.
> > 
> > IMHO the Guix behaviour of always setting a value is the right one
> > (explicit is better than implicit after all).  As for the default
> > values, one might disagree as to which fits, but I don't think
> > ignoring lid switches while powered is harmful.
> > 
> 
> What would you advise if there's no battery power,
> or for some reason one is running on plug power only,
> for worriers that the bulding power might fail?
> 
> I'd guess a power brick would power for some milliseconds 
> and wonder if this is detectable, i.e., to do something
> at least to leave a goodbye world message somewhere if the machine
> was not suspended with sufficient state to resume after power
> restore?
> 
> Buy a UPS, and don't go away long enough for that to run out? :)
I do think that we're starting to split hairs here, but for the sake of
the argument, elogind should be able to detect whether or not the power
supply it's attached to actually delivers power.  If your laptop
doesn't have a battery, then pulling the plug on it has the same
effects as pulling the plug on a regular PC, there's nothing you can do
in elogind to make that a safe action.

Cheers