bug#57919: xscreensaver 6.04 "Authentication failed" error with correct password

[Christine Lemmer-Webber]

Duplicate of #57071, closing.

(And yes, it's unfortunate.  I miss xscreensaver.)

Nathan Dehnel  writes:

> If I attempt to lock the screen, it locks with "xflock" instead of
> xscreensaver. If I run "xscreensaver-demo", I get
>
> "The XScreenSaver daemon doesn't seem to be running on display ":1.0".
> Launch it now?"
>
> If I click "yes", then xscreensaver starts running when the computer
> is locked, but I get "Authentication failed", and I have to switch
> TTYs and killall xscreensaver to get back into my desktop.
> Config:
>   (screen-locker-service xscreensaver "xscreensaver")

bug#58451: cool-retro-term's fonts are broken

[Christine Lemmer-Webber]

I realize we've made some modifications to cool-retro-term's font stuff
back in Bavier's original patches adding cool-retro-term.  Particularly,
some mentions of fonts are emoved.  However, something has gone wrong,
you can no longer increase font sizes, and there aren't really any fonts
listed.  The culprit seems hinted by looking at the output from running
cool-retro-term from another terminal:

qrc:/Fonts.qml:206:1: Expected token `}'
qrc:/Fonts.qml:206:1: Expected token `}'
qrc:/ApplicationSettings.qml:173: TypeError: Cannot read property 'count' of 
undefined
qrc:/ApplicationSettings.qml:126: TypeError: Cannot read property 'fontlist' of 
null

I'm guessing the code that's trying to remove mentions of forbidden
fonts is accidentally dropping a closing brace somehow.

bug#54812: ‘guix system reconfigure’ closes SSH connections

[Christine Lemmer-Webber]

Christine Lemmer-Webber  writes:

> Ludovic Courtès  writes:
>
>> Ludovic Courtès  skribis:
>>
>>> With OpenSSH turned into inetd style in commit
>>> 808b9e850491c7b1d867a5f1f4d5ee6f61f345d4, the service upgrade code used
>>> by ‘guix system reconfigure’ and ‘guix deploy’ wrongfully decides that
>>> the ‘sshd-*’ transient services corresponding to individual SSH
>>> connections should be closed:
>>
>> Fixed with:
>>
>>   eeb8ac43c8 services: shepherd: Do not unload transient services.
>>   a2c759c830 services: herd: Report whether a service is transient.
>>
>> Ludo’.
>
> Hm.  I'm getting this issue.  I did a guix pull locally, on the
> server... doesn't seem to make a difference.  I get the very error
> reported above when using "guix deploy".
>
> I guess others aren't?  I wonder why I am...
>
>  - Christine

I reopened this, because I'm hitting it on all the machines I use "guix
deploy" with.  I think, before closing, it would be good to hear if any
other guix deploy users are hitting it.  If it's just me, well I'll have
to figure it out then, but I suspect it isn't just me. :)

bug#54812: ‘guix system reconfigure’ closes SSH connections

[Christine Lemmer-Webber]

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> With OpenSSH turned into inetd style in commit
>> 808b9e850491c7b1d867a5f1f4d5ee6f61f345d4, the service upgrade code used
>> by ‘guix system reconfigure’ and ‘guix deploy’ wrongfully decides that
>> the ‘sshd-*’ transient services corresponding to individual SSH
>> connections should be closed:
>
> Fixed with:
>
>   eeb8ac43c8 services: shepherd: Do not unload transient services.
>   a2c759c830 services: herd: Report whether a service is transient.
>
> Ludo’.

Hm.  I'm getting this issue.  I did a guix pull locally, on the
server... doesn't seem to make a difference.  I get the very error
reported above when using "guix deploy".

I guess others aren't?  I wonder why I am...

 - Christine

bug#54385: xscreensaver seems to be missing xscreensaver-demo

[Christine Lemmer-Webber]

xscreensaver-demo makes it sound fairly unimportant, but -demo is how
you launch the configuration GUI and select screensavers, turn on
settings like when to lock, etc.  For example, in XFCE, I went to click
on the menus to select "screensaver" and it said xscreensaver-demo was
missing.  I imagine this could be confusing.  It confused me.

Looks like we're not the only ones hitting this issue:

  https://bugs.gentoo.org/753905

Tobias Geerinckx-Rice  writes:

> Hi Christine,
>
> Note that the name of this tool has changed upstream[0], but we're
> still on an older version for now.  Building it:
>
> Warning: GTK version 2.24.33 was found, but at least one supporting
>  library (gdk-pixbuf-xlib-2.0) was not, so GTK can't be
>  used.
>  Perhaps some of the development packages are not installed?
>
> Warning: The GTK libraries do not seem to be available; the
>  `xscreensaver-demo' program requires them.
>
> Where gdk-pixbuf-xlib is of course ‘a deprecated library’ and ‘[n]o
> newly written code should ever use this library’ so that'll be fun to 
> maintain the coming years.
>
> Our gdk-pixbuf package still mentions gdk-pixbuf-xlib-2.0.pc in an
> obsolete comment but doesn't actually install it.
>
> Oh:
>
>   NEWS: - Split the gdk-pixbuf-xlib library to a separate repository
>
> The repository is archived and read-only:
>
>   https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib
>
> Oh that is going to be *super* fun to maintain.
>
> At this point I'd usually go ahead and package the beast, but I don't
> use xscreensaver.  How important is this binary?  (-demo sounds 
> unimportant, -settings very, but it's presumably the same thing.)
>
> In any case an update to xscreensaver would seem prudent first.
>
> Kind regards,
>
> T G-R
>
> Sent from a Web browser.  Excuse or enjoy my brevity.
>
> [0]: https://www.jwz.org/xscreensaver/changelog.html

bug#54385: xscreensaver seems to be missing xscreensaver-demo

[Christine Lemmer-Webber]

Not sure why but the latest xscreensaver package no longer includes the
xscreensaver-demo executable afaict?

bug#53141: installer failed in mkfs.ext4 when installing to the same USB drive

[Christine Lemmer-Webber]

I wonder if what you're really looking for is "guix system image", which
will build something that is basically "pre-configured" for bootable
media you can use:

  https://guix.gnu.org/cookbook/en/html_node/Guix-System-Image-API.html

However, I'm not sure how to combine it with an encrypted volume.

(One advantage of this path is that you can test your built image in a
VM before you try booting it and writing it to a USB key, btw.)

Dan Connolly  writes:

> I'm installing from a USB thumb drive. I'd like to use the thumb drive
> as the disk for the machine. The installer gave me the option to do
> so, but then it crashed.
>
> I can imagine that installing on the installation media is not
> supported. Perhaps the installer should have prevented me from doing
> so?
>
> p.e. Please excuse the use of an image of the text. I see "The
> backtrace is displayed below. Please report it by email ..." and I the
> only option that occurs to me is to take an image and send it from
> another computer.

bug#50896: emacs-beancount broken, moved to its own project

[Christine Lemmer-Webber]

Thank you... did all the above and pushed!  The emacs-beancount package
is sensibly alive again!

bug#50872: Prosody service + letsencrypt certs improvements

[Christine Lemmer-Webber]

Carlo Zancanaro  writes:

> Hi Christine,
>
> On Tue, Sep 28 2021, Christine Lemmer-Webber wrote:
>> Hm, in other words we really ought to run this attached to some hook
>> related to the letsencrypt services... when they renew successfully,
>> it should trigger this command, I'd think.  We do similar things for
>> nginx, etc...
>
> I'm pretty sure Guix doesn't do anything automatic when certificates
> are renewed. For nginx there's an example in the manual for how to set
> up a deploy hook to reload the certificates[1], so I expect that
> you'll have to set up something similar.

You're right... not sure why I thought it did.

> My prosody setup has this deploy hook:
>
>(program-file
> "reload-certificates"
> #~(let ((prosodyctl (string-append #$(specification->package
>  "prosody")
>"/bin/prosodyctl")))
> (system* prosodyctl "--root" "cert" "import"
> "/etc/letsencrypt/live")
> (system* prosodyctl "reload")))
>
> but I have recently had some trouble with it (prosody hasn't been
> reloading the certificate properly). I don't think my issue is 
> related to this deploy hook, though.

That seems great.  I'll give it a try.

Since this isn't significantly different from other services then (well,
excepting that prosody needs to not just reload but have the import
command run again... but you've provided what looks like a good solution
above) I'm going to close this.

> I hope that helps!

It does, thanks!

> Carlo
>
> [1]:
> https://guix.gnu.org/en/manual/en/html_node/Certificate-Services.html

bug#50896: emacs-beancount broken, moved to its own project

[Christine Lemmer-Webber]

Hello... emacs-beancount is broken because it's no longer just bundled
in beancount.  However, I've attached a fix.

If nobody has any problem with this I'll just push it up to master.
Since it's a leaf package, and the current state is "it's broken" I
figure it's probably fine to push, but since it's a significant
refactoring thought I'd ask for a review before I did so.

From e6f150f3eb3f3f63455c2a21a9490690b59216f2 Mon Sep 17 00:00:00 2001
From: Christine Lemmer-Webber 
Date: Wed, 29 Sep 2021 12:46:01 -0400
Subject: [PATCH] gnu: emacs-beancount: Restructure package, now independent of
 beancount.

* gnu/packages/finance.scm (emacs-beancount): Restructure package, now
independent of beancount and in its own git repository.  Note that there is no
version number for the now independent code tree, so unfortunately this might
look like a "version downgrade" to some users as it switched from being
beancount's revision number to being a git-derived version number.
---
 gnu/packages/finance.scm | 41 ++--
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/gnu/packages/finance.scm b/gnu/packages/finance.scm
index 4aaab58906..e554d93535 100644
--- a/gnu/packages/finance.scm
+++ b/gnu/packages/finance.scm
@@ -1643,25 +1643,30 @@ define financial transaction records in a text file, read them in memory,
 generate a variety of reports from them, and provides a web interface.")
 (license license:gpl2)))
 
-;; The beancount source ships with elisp in a subdirectory
 (define-public emacs-beancount
-  (package
-(inherit beancount)
-(name "emacs-beancount")
-(build-system emacs-build-system)
-(arguments
- `(#:tests? #f ;no tests
-   #:phases
-   (modify-phases %standard-phases
- (add-before 'install 'chdir-emacs
-   (lambda _
- (chdir "editors/emacs")
- #t)
-(inputs '())
-(native-inputs '())
-(synopsis "Emacs mode for beancount")
-(description
-  "Emacs-beancount is an Emacs mode for the Beancount accounting tool.")))
+  (let ((commit "dbafe6a73d90c1f64d457b356b9dbb43499f70d5")
+(revision "0"))
+(package
+  (name "emacs-beancount")
+  (version (git-version "0.0.0" revision commit))
+  (source
+   (origin
+ (method git-fetch)
+ (uri (git-reference
+   (url "https://github.com/beancount/beancount-mode;)
+   (commit commit)))
+ (sha256
+  (base32
+   "0v9bws2gv5b00x829p7hrcxqgdp7iwxvv1vhfjka81qrw6w1fvjw"))
+ (file-name (git-file-name name version
+  (build-system emacs-build-system)
+  (license license:gpl3+)
+  (home-page "https://github.com/beancount/beancount-mode;)
+  (inputs '())
+  (native-inputs '())
+  (synopsis "Emacs mode for beancount")
+  (description
+   "Emacs-beancount is an Emacs mode for the Beancount accounting tool."
 
 (define-public hledger-web
   (package
-- 
2.33.0



signature.asc
Description: PGP signature

bug#50872: Prosody service + letsencrypt certs improvements

[Christine Lemmer-Webber]

I finally got prosody working on my server using Guix.  However, the
manual says:

   Prosodyctl will also help you to import certificates from the
   ‘letsencrypt’ directory so that the ‘prosody’ user can access them.  See
   .

 prosodyctl --root cert import /etc/letsencrypt/live

However, what prosody actually does with this command is that it copies
the files from letsencrypt *over to* its own directory (but then also
restarts prosody... in theory).  According to the docs:

  This command can be put in cron or passed as a callback to automated
  certificate renewal programs such as certbot or other Let's Encrypt
  clients. For more information on using Prosody with these, see our
  Let's Encrypt page.

Hm, in other words we really ought to run this attached to some hook
related to the letsencrypt services... when they renew successfully, it
should trigger this command, I'd think.  We do similar things for nginx,
etc...

Thoughts?  Does this seem right?
 - Christine

bug#50441: Wrong build directory number shown in environment-variables file

[Christine Lemmer-Webber]

Hi Tobias!

Tobias Geerinckx-Rice  writes:

> [[PGP Signed Part:Undecided]]
> Christine,
>
> Christine Lemmer-Webber 写道：
>> I was doing guix build with "--keep-missing" and looking around in a
>> few
>> of the output directories.  I was peeking in:
>>
>>   /tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-4
>>
>> But wait... the "environment-variables" file says:
>>
>> #+BEGIN_SRC sh
>> export TEMP=\
>> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
>
> Part of the build environment isolation/reproducibility is that
> processes inside it always see a build directory ending in ‘-0’, 
> regardless of the file name on the host system.
>
> Kind regards,
>
> T G-R
>
> [[End of PGP Signed Part]]

This makes sense in general, though I wonder if when using --keep-failed
if environment-variables should dump out something different, since
that file is around for debugging, and sourcing it might set up the
wrong paths I guess?  What do you think?

bug#50441: Wrong build directory number shown in environment-variables file

[Christine Lemmer-Webber]

Loops like Tobias gave the explanation in their reply:

> Part of the build environment isolation/reproducibility is that
> processes inside it always see a build directory ending in ‘-0’, 
> regardless of the file name on the host system.

Sarah Morgensen  writes:

> Hello Christine,
>
> Christine Lemmer-Webber  writes:
>
>> I was doing guix build with "--keep-missing" and looking around in a few
>> of the output directories.  I was peeking in:
>>
>>   /tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-4
>>
>> But wait... the "environment-variables" file says:
>>
>> #+BEGIN_SRC sh
>> export TEMP=\
>> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
>> export TEMPDIR=\
>> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
>> export TMP=\
>> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
>> export TMPDIR=\
>> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
>> #+END_SRC
>>
>> Now wait a minute.  Look at that last number.  What the hell is going on
>> here?  Is this a bug in Guix?  Why is it pointing at -0 in the -4 build
>> directory?
>>
>> Does this point at a more serious issue?  What's going on?
>
> I've definitely noticed this before as well, and had to work around it
> (I needed to inspect temp caches).  Thanks for actually sending a bug
> report :)
>
> I'm not at all familiar with the nix code, but it looks like this might
> be related:
>
> nix/libstore/build.cc:1654
>
> /* In a sandbox, for determinism, always use the same temporary
>directory. */
> tmpDirInSandbox = useChroot ? canonPath("/tmp", true) + "/guix-build-" + 
> drvName + "-0" : tmpDir;
>
> /* For convenience, set an environment pointing to the top build
>directory. */
> env["NIX_BUILD_TOP"] = tmpDirInSandbox;
>
> /* Also set TMPDIR and variants to point to this directory. */
> env["TMPDIR"] = env["TEMPDIR"] = env["TMP"] = env["TEMP"] = 
> tmpDirInSandbox;
>
> /* Explicitly set PWD to prevent problems with chroot builds.  In
>particular, dietlibc cannot figure out the cwd because the
>inode of the current directory doesn't appear in .. (because
>getdents returns the inode of the mount point). */
> env["PWD"] = tmpDirInSandbox;
>
> I'm not entirely sure what's going on.  I think we build in chroot by
> default, which would explain why the temp vars get set to "-0" even
> though everything else seems to work okay.

bug#50441: Wrong build directory number shown in environment-variables file

[Christine Lemmer-Webber]

I was doing guix build with "--keep-missing" and looking around in a few
of the output directories.  I was peeking in:

  /tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-4

But wait... the "environment-variables" file says:

#+BEGIN_SRC sh
export TEMP=\
"/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
export TEMPDIR=\
"/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
export TMP=\
"/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
export TMPDIR=\
"/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
#+END_SRC

Now wait a minute.  Look at that last number.  What the hell is going on
here?  Is this a bug in Guix?  Why is it pointing at -0 in the -4 build
directory?

Does this point at a more serious issue?  What's going on?