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

[Cairn via Bug reports for GNU Guix]

"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.

[1]: https://www.freedesktop.org/software/systemd/man/logind.conf.html

signature.asc
Description: OpenPGP digital signature

bug#57049: cool-retro-term-1.2.0 build failure

[宋文武 via Bug reports for GNU Guix]

"bdju"  writes:

> build log: http://ix.io/46Yn
> guix version: just shows up as 0 for some reason...

cool-retro-term fixed in master now, thank you for the report!

I have version as 0 too...

bug#57037: Package `guile-newt' cannot be cross-compiled

[Mathieu Othacehe]

Hello,

> The `guile-newt' package that is used for the installation UI can't
> be cross-compiled as it tries to load the `newt' dynamic library when
> the Guile code is compiled. I've tried to find a solution/fix but I
> don't know much about how Guile byte-code compilation works.

Fixed with bde902cb78c529174155e2d46ed814123182619f.

> I think this is one of the last remaining bits before being able to
> fully cross compile an installation image.

I think that guile-parted will also be problematic.

Thanks,

Mathieu

bug#56965: wterm does not work on sway

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

August 6, 2022 3:45 PM, b...@bokr.com wrote:

> Hi Joshua,
> 
> On +2022-08-03 21:54:12 -0400, Joshua Branson via Bug reports for GNU Guix 
> wrote:
> 
>> wterm is said to be a simple terminal for wayland:
>> 
>> #+BEGIN_SRC shell :results: raw
>> guix show wterm | recsel -p synopsis
>> #+END_SRC
>> 
>> #+RESULTS:
>> : synopsis: Terminal emulator for Wayland
>> 
>> Well, when I try to use it, I get the following error on sway. wterm
>> does not start.
>> 
>> joshua@crazyhorse ~ (master)> wterm
>> wl_drm@11: error 0: authenticate failed
>> # wayland_create_context: DRM authentication failed
>> # wayland_create_context: No wl_shm global
>> # wld_wayland_create_context: Could not initialize any of the specified 
>> implementations
>> Can't create wayland context
>> 
>> Thanks,
>> 
>> Joshua
> 
> Might you need to add video and maybe audio groups to your set of groups?

I have those set for my regular user.  I did not try to run the command as 
root.  :)

Patch https://issues.guix.gnu.org/57014 seems to have a patch to deprecate 
wterm,
if this is the direction that we decide to take.  

> 
> What do you get from
> id $USER
> or
> groups
> or, to see who else you share groups with
> grep $USER /etc/groups
> for adding groups to those you already have, I think check the -aG option
> info usermod
> I don't dare suggest the actual command for your system, so
> you're on your own. If you have the sudo group, id $USER should show it,
> and that's probably easier. If you go into root, you don't want
> to add video,audio to root, so IIRC the options are a little different
> to make sure you as $USER get the added groups, not root.
> (BTW, try typing "id root" ;)
> 
> HTH
> --
> Regards,
> Bengt Richter

bug#57046: (No Subject)

[Jean Pierre De Jesus DIAZ via Bug reports for GNU Guix]

FWIW author cites:

https://guix.gnu.org/es/manual/es/guix.es.html#DOCF50

As the reason for using feminine words.

https://guix.gnu.org/es/manual/es/guix.es.html#FOOT50

Quoting from the manual:

>NdT: En esta traducción se ha optado por usar el femenino para referirse a 
>personas, ya que es el género gramatical de dicha palabra. Aunque las 
>construcciones impersonales pueden adoptarse en la mayoría de casos, también 
>pueden llegar a ser muy artificiales en otros usos del castellano; en 
>ocasiones son directamente imposibles. Algunas construcciones que proponen la 
>neutralidad de género dificultan la lectura automática (-x), o bien dificultan 
>la corrección automática (-e), o bien aumentan significativamente la 
>redundancia y reducen del mismo modo la velocidad en la lectura (-as/os, -as y 
>-os). No obstante, la adopción del genero neutro heredado del latín, el que en 
>castellano se ha unido con el masculino, como construcción neutral de género 
>se considera inaceptable, ya que sería equivalente al “it” en inglés, nada más 
>lejos de la intención de las autoras originales del texto.

>En esta traducción se ha optado por usar el femenino para referirse a 
>personas, ya que es el género gramatical de dicha palabra.

Yes, right, "personas" is feminine, but doesn't mean "usuario" has to be changed
to a feminine word just because the word we use to designate people is feminine,
it has no relation. An user can not only represent people, but an organization,
a team, etc.

>la adopción del genero neutro heredado del latín, el que en castellano se ha 
>unido con el masculino, como construcción neutral de género se considera 
>inaceptable

That's not a fact, it's an opinion, and a very personal one.

>nada más lejos de la intención de las autoras originales del texto.

This one, here it's written as "autoras" as feminine when "autores" is already
a neutral word, it's doesn't refer to a man nor a woman, just a group of people
that authored something. So, if Spanish has already gendered words, with 
masculine,
feminine and neutral, and a neutral word is already available, then what's the 
real
intention of the author of that foot note?

---

I feel like the guideline for writing using neutral words was taken out of 
context
and abused for personal purposes.

—
Jean-Pierre De Jesus DIAZ

bug#57046: Spanish documentation uses exclusive language

[Jean Pierre De Jesus DIAZ via Bug reports for GNU Guix]

Hello,

As an Spanish speaker too I didn't notice it at first when reading
the documentation and feels weird that it's deliberately "usuaria"
instead of "usuario".

For example, in Argentina, only 8% of the population uses inclusive
language:

https://www.diariodecultura.com.ar/columna-izquierda/solo-el-8-de-la-poblacion-utiliza-el-lenguaje-inclusivo-con-frecuencia/

Couldn't find more statistics on the matter.

Not only using "usuaria" it's exclusive but it's also grammatically
incorrect, the proper way would be using "usuario" which includes
all genders and "usuario y usuaria", but it is too verbose IMHO.

For example:

- "Cuentas de usuario"
- "Cuentas de usuario y usuaria"

The latter one is used a lot by the Venezuelan government when
they try to be inclusive, but it's tiring to the reader and
doesn't provide additional context.

>Swapping masculine forms with their feminine counterpart and pretending 
>they're neutral creates a problem on top of a problem.

Completely agree.

—
Jean-Pierre De Jesus DIAZ

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

[Liliana Marie Prikler]

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.

Cheers

bug#57046: Spanish documentation uses exclusive language

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

I applaud your effort using inclusive language in the official documentation, 
as someone who uses it daily in most occasions. Sadly, I've seen some 
concerning issues in the Spanish documentation related to the usage of 
inclusive language, specifically in the manual 
(https://guix.gnu.org/es/manual/es/guix.es.html)

There are references everywhere to "usuaria", the feminine form of "usuario" 
(user). Like for example the title of point 10.5: "Cuentas de usuaria", or in 
2.1.2: "la usuaria root".

Using the feminine form "usuaria" like it was neutral is as exclusive (if not 
more, since that's done consciously) as using the masculine form. If you want 
to make "usuario" neutral, please use alternative ways like making up neutral 
words using the "e" or the "x": "le usuarie root" / "lx usuarix root".

To give some context, in Spanish, inclusive language still isn't academically 
accepted, the way to refer to some person or group in a neutral way is usually 
using the masculine forms as neutral forms. Now, the few of us who have been 
doing efforts for years using inclusive language to be respectful with every 
sensitivity, try to avoid using masculine forms as neutral, and reword 
sentences or use equivalent gender neutral words when those exist. This 
requires effort since Spanish is a heavily gendered language, and sometimes it 
isn't possible, like in the "usuario" example above. In those cases the trend 
is to make up neutral words like I pointed out. Swapping masculine forms with 
their feminine counterpart and pretending they're neutral creates a problem on 
top of a problem.
 
-- 
Sincerely,
L. F. Vega

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

Cc to the Spanish translators in po/doc/guix-manual.es.po

Thank you Jean Pierre De Jesus DIAZ for filing a bug instead of starting
an edit war on Weblate.  But if there is a decision on changing, someone
will have to edit the translation on Weblate.

For comparison,

* 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)
  


Regards,
Florian

bug#57059: [BUG] pcc build failure

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

The build for the `pcc` compiler is broken on my machine (x86-64):

```log
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/vdhsdhk6cgsw3vajwfkq6jwr1w2lpbx3-bison-3.7.6/bin:/gnu/store/b4mskl4py1zqmxdy1v260r3h6x5p92fm-flex-2.6.4/bin:/gnu/store/g2ajyl8xk9aarxrgjbng2hkj3qm2v0z2-tar-1.34/bin:/gnu/store/iixwcv3k49ks1rf34pjgfzmzyhhgwng3-gzip-1.10/bin:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/bin:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/bin:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/bin:/gnu/store/ahmmvw21p11ik80lg1f953y7fd8bqkjm-diffutils-3.8/bin:/gnu/store/z39hnrwds1dgcbpfgj8dnv2cngjb2xbl-patch-2.7.6/bin:/gnu/store/39rsx3nl4c31952jybbjb8d6idr5hx7r-findutils-4.8.0/bin:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/bin:/gnu/store/wxgv6i8g0p24q5gcyzd0yr07s8kn9680-sed-4.8/bin:/gnu/store/xjwp2hsd9256icjjybfrmznppjicywf6-grep-3.6/bin:/gnu/store/d251rfgc9nm2clzffzhgiipdvfvzkvwi-coreutils-8.32/bin:/gnu/store/55cbpsi18mahg131nmiya6km5b4mscfa-make-4.3/bin:/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin:/gnu/store/s2pg5k98fl2g2szg9dykxyd9zl3xihv9-ld-wrapper-0/bin:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/bin:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/bin:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/bin:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/sbin:/gnu/store/gwrii9zfm1vl70cx3z16i0s5wbvng997-m4-1.4.18/bin'
environment variable `BASH_LOADABLES_PATH' unset
environment variable `C_INCLUDE_PATH' set to 
`/gnu/store/b4mskl4py1zqmxdy1v260r3h6x5p92fm-flex-2.6.4/include:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/include:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/include:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/include:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/include:/gnu/store/55cbpsi18mahg131nmiya6km5b4mscfa-make-4.3/include:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/include:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include:/gnu/store/6mjww4iz4xdan74d5bbjfh7il8rngfkk-linux-libre-headers-5.10.35/include'
environment variable `CPLUS_INCLUDE_PATH' set to 
`/gnu/store/b4mskl4py1zqmxdy1v260r3h6x5p92fm-flex-2.6.4/include:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/include:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/include:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/include:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/include:/gnu/store/55cbpsi18mahg131nmiya6km5b4mscfa-make-4.3/include:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/include:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++:/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include:/gnu/store/6mjww4iz4xdan74d5bbjfh7il8rngfkk-linux-libre-headers-5.10.35/include'
environment variable `LIBRARY_PATH' set to 
`/gnu/store/vdhsdhk6cgsw3vajwfkq6jwr1w2lpbx3-bison-3.7.6/lib:/gnu/store/b4mskl4py1zqmxdy1v260r3h6x5p92fm-flex-2.6.4/lib:/gnu/store/s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8/lib:/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5/lib:/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39/lib:/gnu/store/690qz3fg334dpwn3pn6k59n4wc943p2b-gawk-5.1.0/lib:/gnu/store/rc781v4k0drhaqn90xfwwpspki5x0bvf-binutils-2.37/lib:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib:/gnu/store/4jdghmc65q7i7ib89zmvq66l0ghf7jc4-glibc-2.33-static/lib:/gnu/store/fnr1z6xsan0437r0yg48d0y8k32kqxby-glibc-utf8-locales-2.33/lib'
environment variable `GUIX_LOCPATH' set to 
`/gnu/store/fnr1z6xsan0437r0yg48d0y8k32kqxby-glibc-utf8-locales-2.33/lib/locale'
phase `set-paths' succeeded after 0.0 seconds
starting phase `install-locale'
using 'en_US.utf8' locale for category "LC_ALL"
phase `install-locale' succeeded after 0.0 seconds
starting phase `unpack'
pcc-20170109
pcc-20170109/CVS
pcc-20170109/CVS/Root
pcc-20170109/CVS/Repository
pcc-20170109/CVS/Entries
pcc-20170109/DATESTAMP
pcc-20170109/Makefile.in
pcc-20170109/config.guess
pcc-20170109/config.h.in
pcc-20170109/config.sub
pcc-20170109/configure
pcc-20170109/configure.ac
pcc-20170109/install-sh
pcc-20170109/arch
pcc-20170109/arch/CVS
pcc-20170109/arch/CVS/Root
pcc-20170109/arch/CVS/Repository
pcc-20170109/arch/CVS/Entries
pcc-20170109/arch/amd64
pcc-20170109/arch/amd64/CVS
pcc-20170109/arch/amd64/CVS/Root
pcc-20170109/arch/amd64/CVS/Repository
pcc-20170109/arch/amd64/CVS/Entries
pcc-20170109/arch/amd64/code.c
pcc-20170109/arch/amd64/local.c
pcc-20170109/arch/amd64/local2.c
pcc-20170109/arch/amd64/macdefs.h
pcc-20170109/arch/amd64/order.c
pcc-20170109/arch/amd64/table.c
pcc-20170109/arch/arm
pcc-20170109/arch/arm/CVS
pcc-20170109/arch/arm/CVS/Root
pcc-20170109/arch/arm/CVS/Repository
pcc-20170109/arch/arm/CVS/Entries
pcc-20170109/arch/arm/

bug#57046: Spanish documentation uses exclusive language

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

Sorry! I honestly didn't see the author reasoning for using feminine words. 
Thank you so much for pointing me to the relevant notes.

According to their reasoning, using made up neutrals like "-x" or "-e" make 
automatic reading or autocorrection difficult, and  using "-as/os" would be too 
verbose. While I agree with the author on those, we should have in mind that 
from the moment we decide to use inclusive language we have to make sacrifices. 
That's an inescapable fact, since the inclusive language options in Spanish 
when neutral masculines referring to people can't be avoided, are either a) 
made-up and aren't grammatically correct, or b) too verbose. So someone should 
decide what the priority is whenever neutral masculines can't be avoided.

- If we care more about inclusive language and don't mind using made up 
neutrals, we can use "lx usuarix root" (-x) or "le usuarie root" (-e). This is 
inclusive, but not grammatically correct and sacrifices readability.

- If we care about inclusive language and correctness, we can use "el/la 
usuario/a root", "la o el usuario root" or "la usuaria o usuario root" 
(-as/-os). This is inclusive, grammatically correct, but adds verbosity and 
minorities claim that doesn't address non-binary people.

- If we only care about readability and correctness, we can use masculines as 
neutrals: "el usuario root". This is grammatically correct and used/understood 
by most, but isn't considered inclusive language.

There isn't a perfect solution, and while I personally prefer the (-e) or (-x), 
I'm fine if any other approach is accepted, even if it's the third one. But, as 
you also pointed out, using feminine forms as neutrals by default isn't 
appropiate. It has the worst of all worlds: is purposely exclusive, uncommon 
and grammatically incorrect. I'm also clueless about the author intentions, all 
I know is that the Spanish word for "people" being feminine doesn't justify 
swapping all the people-related words to their feminine counterparts.

-- 
Sincerely,
L. F. Vega


8 ago 2022, 13:01 por bug-guix@gnu.org:

> FWIW author cites:
>
> https://guix.gnu.org/es/manual/es/guix.es.html#DOCF50
>
> As the reason for using feminine words.
>
> https://guix.gnu.org/es/manual/es/guix.es.html#FOOT50
>
> Quoting from the manual:
>
> >NdT: En esta traducción se ha optado por usar el femenino para referirse a 
> >personas, ya que es el género gramatical de dicha palabra. Aunque las 
> >construcciones impersonales pueden adoptarse en la mayoría de casos, también 
> >pueden llegar a ser muy artificiales en otros usos del castellano; en 
> >ocasiones son directamente imposibles. Algunas construcciones que proponen 
> >la neutralidad de género dificultan la lectura automática (-x), o bien 
> >dificultan la corrección automática (-e), o bien aumentan significativamente 
> >la redundancia y reducen del mismo modo la velocidad en la lectura (-as/os, 
> >-as y -os). No obstante, la adopción del genero neutro heredado del latín, 
> >el que en castellano se ha unido con el masculino, como construcción neutral 
> >de género se considera inaceptable, ya que sería equivalente al “it” en 
> >inglés, nada más lejos de la intención de las autoras originales del texto.
>
> >En esta traducción se ha optado por usar el femenino para referirse a 
> >personas, ya que es el género gramatical de dicha palabra.
>
> Yes, right, "personas" is feminine, but doesn't mean "usuario" has to be 
> changed
> to a feminine word just because the word we use to designate people is 
> feminine,
> it has no relation. An user can not only represent people, but an 
> organization,
> a team, etc.
>
> >la adopción del genero neutro heredado del latín, el que en castellano se ha 
> >unido con el masculino, como construcción neutral de género se considera 
> >inaceptable
>
> That's not a fact, it's an opinion, and a very personal one.
>
> >nada más lejos de la intención de las autoras originales del texto.
>
> This one, here it's written as "autoras" as feminine when "autores" is already
> a neutral word, it's doesn't refer to a man nor a woman, just a group of 
> people
> that authored something. So, if Spanish has already gendered words, with 
> masculine,
> feminine and neutral, and a neutral word is already available, then what's 
> the real
> intention of the author of that foot note?
>
> ---
>
> I feel like the guideline for writing using neutral words was taken out of 
> context
> and abused for personal purposes.
>
> —
> Jean-Pierre De Jesus DIAZ
>

bug#47222:

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

We now have nettle 3.7.3, so this isn't an issue anymore. Closing.

-- (

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

[Attila Lendvai]

i got back online...


> 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.


i agree.


> With the xvnc example, I better understand the kind of situation where
> a field value might end up directly in a gexp, though I’m still unsure
> whether use of unspecified really makes things worse. At least,
> because it lacks a read syntax, the problem is caught early on; whereas
> with 'unset, you might end up stuffing 'unset in your config file
> without noticing.


i agree with this, too.

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...

i think moving back from *UNSPECIFIED* to using 'UNSET only has drawbacks. and 
if it works (read: it doesn't error out while guix is deploying the config), 
then it probably produces illegal config files by serializing the unspecified 
value into an "unset" string in the config files.

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).

either way, if there was a failing test case that i could run locally, then i 
would have been more than happy to fix it... now i'm only dismayed that all my 
service code, and my entire channel got broken. seems like i went offline in 
the worst two weeks.

sidenote: what srfi-189 does is basically introduce such a special value that 
we are trying to hone in on here (i.e. Nothing, which is implemented as a 
record instance) in a standardized way, and also an API to deal with this 
special value in various different contexts (i.e. it exports stuff like 
MAYBE-IF, MAYBE-FOLD, MAYBE-AND, etc).

https://srfi.schemers.org/srfi-189/srfi-189.html

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Although teachers do care and do work very, very hard, the institution is 
psychopathic-it has no conscience. It rings a bell and the young man in the 
middle of writing a poem must close his notebook and move to a different cell 
where he must memorize that humans and monkeys derive from a common ancestor.”
— John Taylor Gatto (1935–), 'Dumbing Us Down: The Hidden Curriculum of 
Compulsory Education' (1992)

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

[Attila Lendvai]

> 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.

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.

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

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

2) has non-trivial uncertainties/complexities in making srfi-189 available in 
all the required contexts, and not introducing any bootstrap related issues in 
the process. because of that i would recommend getting to 2) by first 
implementing 1) and then working towards 2) -- if we want to use srfi-189 at 
all, that is.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“What's done to children, they will do to society.”
— Karl A. Menninger (http://psychohistory.com/)

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

[bokr]

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? :)

> Cheers
> 
--
Regards,
Bengt Richter

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