bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

[Mark H Weaver]

Hi Ricardo,

Ricardo Wurmus  writes:

>> However, in both EWW and Lynx, the embedded patches are rendered
>> double-spaced, i.e. there are empty lines inserted between every two
>> adjacent lines of every patch.  I guess that's because Mumi wraps each
>> individual line within its own 'pre' and 'div' elements, instead of
>> putting the entire patch within a single 'pre' element.
>
> It does indeed wrap each line, because otherwise we can’t style the
> lines e.g. to highlight additions with green and deletions with red.

I think I've found a way to fix the double-spacing problem in EWW and
Lynx without sacrificing styling: put the entire patch within a single
'pre' element, and then put each line within a 'span' element.  The
styling of each line can then be applied to the 'span's.

What do you think?

  Regards,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#52533: [PATCH] bug#52533: guix deploy breaks SSH access with a PAM error

[Maxim Cournoyer]

Hello,

I've found a workaround: disabling PAM for the remote machine
ssh-daemon.  This is not done as part of 'guix deploy', so needs to be
fiddled with manually; I did it this way:

1. take note of the command line and sshd_config file:

--8<---cut here---start->8---
ps -eFww | grep sshd
--8<---cut here---end--->8---

2. Copy the sshd_config file from /gnu/store to somewhere writable and
edit it so tha UsePAM is "no" instead of "yes".

3. Stop the Shepherd service with 'sudo herd stop ssh-daemon'

4. Start the ssh daemon manually (with sudo) by using the command found
in 1. but with the edited config from 2.

Then you should be able to 'guix deploy' successfully.

Reading 'man sshd_config', it says the default for UsePAM is no.
Considering this, and the issue it caused reported here, perhaps we
should disable it by default in Guix?

What do others think?

Thank you,

Maxim

bug#52533: guix deploy breaks SSH access with a PAM error

[Maxim Cournoyer]

Hello Guix!

Following the big merge of the core-updates-frozen branch into master,
I've noticed now on two counts the following: running 'guix deploy'
leaves the remote machine unreachable by SSH.  The connection passes
authentication but then gets closed immediately.  /var/log/messages
reveals the following error:

--8<---cut here---start->8---
sshd[29578]:  error: PAM: pam_open_session(): Module is unknown
--8<---cut here---end--->8---

The machines updated were running Guix System revisions predating the
core-updates-frozen merge.

The 'guix deploy' command doesn't succeed due to SSH starting to fail at
99% completion or similar; the bootloader configuration is not updated
so rebooting boots into the same old system generation (and SSH works
again):

--8<---cut here---start->8---
guix deploy: deploying to x200...
guix deploy: sending 0 store items (0 MiB) to 'x200.local'...
guix deploy: sending 0 store items (0 MiB) to 'x200.local'...
substitute: updating substitutes from 'http://127.0.0.1:8181'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
   /gnu/store/049wr939gjpgl3471wrk8b1waqgswrdi-remote-exp.scm.drv
   /gnu/store/y1mgddpa2qkrmc01knpdam917b60yxlq-switch-to-system.scm.drv
   /gnu/store/vgadszcfklbhr7d8yl8jprzipjy6b0vj-system.drv
   /gnu/store/ypyaf6ib1w5nc4kr0xgjm4par407cnzk-provenance.drv

building /gnu/store/ypyaf6ib1w5nc4kr0xgjm4par407cnzk-provenance.drv...
building /gnu/store/vgadszcfklbhr7d8yl8jprzipjy6b0vj-system.drv...
building /gnu/store/y1mgddpa2qkrmc01knpdam917b60yxlq-switch-to-system.scm.drv...
building /gnu/store/049wr939gjpgl3471wrk8b1waqgswrdi-remote-exp.scm.drv...
guix deploy: sending 5 store items (0 MiB) to 'x200.local'...
guix deploy: error: failed to deploy x200: failed to start 'guix repl' on 
'x200.local'

$ guix deploy ~/stow/guix/machines/x200.scm --no-offload
The following 1 machine will be deployed:
  x200

guix deploy: deploying to x200...
guix deploy: error: failed to deploy x200: remote command
'/run/setuid-programs/sudo -n -- guix repl -t machine' failed with
status 254

$ ssh x200
Last login: Wed Dec 15 23:28:02 2021 from 192.168.10.15
Connection to x200.local closed.
--8<---cut here---end--->8---

This is obviously embarrassing in scenarios where the SSH connection is
the main way to reach to the remote machine.

Ideas?

Thank you,

Maxim

bug#52517: inconstency with offloading

[Maxim Cournoyer]

Hello Simon!

zimoun  writes:

> Hi,
>
> The manual provides [1] the example:
>
>   (build-machine
> (name "armeight.example.org")
> (systems (list "aarch64-linux"))
> (host-key "ssh-rsa B3Nza…")
> (user "alice")
> (private-key
>  (string-append (getenv "HOME")
> "/.ssh/identity-for-guix")))
>
>
> but what is not clear is 'getenv' from who.  Concretly, adding 'pk' it
> reads:
>
> $ guix offload test
>
> ;;; ("/home/simon")
> guix offload: testing 2 build machines defined in '/etc/guix/machines.scm'...
>
>
> however, when really building with offload:
>
> $ guix build -L /tmp/mine r-cipr
> The following derivation will be built:
>/gnu/store/mzixy5hhx79xx33k03acaasml87c0knc-r-cipr-0.1.0-1.4b01bb8.drv
>
> ;;; ("/root")

Good observation; a similar issue I had reported is
https://issues.guix.gnu.org/39366.

Maxim

bug#52520: Multicast is off by default

[Mathieu Othacehe]

Hello,

Since the guile-netlink switch the static IP interfaces no longer have
multicast support. This can be confirmed this way:

--8<---cut here---start->8---
4: eno4:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
link/ether b0:26:28:b7:9d:09 brd ff:ff:ff:ff:ff:ff
5: eno2:  mtu 1500 qdisc mq state UP group default qlen 
1000
link/ether b0:26:28:b7:9d:0b brd ff:ff:ff:ff:ff:ff
inet 141.80.181.40/24 brd 141.80.181.255 scope global eno2
   valid_lft forever preferred_lft forever
inet6 fe80::b226:28ff:feb7:9d0b/64 scope link 
   valid_lft forever preferred_lft forever
--8<---cut here---end--->8---

eno2 that is managed by the static-networking service is lacking
multicast support, while eno4 that is not managed by this service has
multicast support.

This can be adjusted by running:

--8<---cut here---start->8---
ip link set multicast on eno1
--8<---cut here---end--->8---

which immediately fixes Avahi discovery that depends on it.

I think that we could maybe apply the following patch, even though I
didn't test it.

--8<---cut here---start->8---
diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 5f93483dda..af3fe015b9 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -2546,6 +2546,7 @@ (define network-set-up/linux
 #$(network-address-ipv6? 
address))
   ;; FIXME: loopback?
   (link-set #$(network-address-device 
address)
+#:multicast-on #t
 #:up #t)))
 addresses)
--8<---cut here---end--->8---

Thanks,

Mathieu

bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

[Michael Rohleder]

Hi Maxim,

I currently have this (very annoying) issue on _one_ of my machines (two
others work with nearly the same config).
I can't login at all not via console nor ssh or sddm.
I spend some time to reproduce it in a vm, but no success so far.

These are the relevant messages from syslog:
Dec 15 18:15:52 micha dbus-daemon[470]: [system] Failed to activate service 
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Dec 15 18:16:47 micha dbus-daemon[470]: [system] Activating service 
name='org.freedesktop.login1' requested by ':1.8' (uid=0 pid=899 
comm="/gnu/store/ximad0zvg12r4x0x80mvym8hzg0n33jl-shadow") (using servicehelper)
Dec 15 18:16:47 micha elogind[935]: elogind is already running as PID 558
Dec 15 18:17:12 micha dbus-daemon[470]: [system] Failed to activate service 
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)

-- 
How much does it cost to entice a dope-smoking UNIX system guru to Dayton?
-- Brian Boyle, UNIX/WORLD's First Annual Salary Survey


signature.asc
Description: PGP signature

bug#52519: glibmm-2.64 propagates two different versions of libsigc++

[Leo Famulari]

glibmm-2.64 has this:

--
 (propagated-inputs
  (modify-inputs (package-propagated-inputs glibmm)
(prepend libsigc++-2)
--

And, the glibmm package also propagates libsigc++.

So:

--
$ guix show glibmm@2.64 | grep libsigc
dependencies: doxygen@1.9.1 glib@2.70.0 graphviz@2.49.0 libsigc++@2.9.3
+ libsigc++@3.0.6 libxslt@1.1.34 m4@1.4.18 mm-common@1.0.3 perl@5.34.0
--

It propagates both versions of libsigc++, and thus cannot be installed
into a profile. 1785 packages depend on glibmm-2.64.

This breaks synfig, which propagates glibmm, as requested in its 'synfig.pc'
pkg-config file.

bug#52501: xcalc seems broken

[Leo Famulari]

On Wed, Dec 15, 2021 at 09:59:48AM +0100, Josselin Poiret wrote:
> issue is that the application is styled using a resource file, in
> ./lib/X11/app-defaults/, which is supposed to be loaded by libxt.
> Looking at gnu/packages/patches/libxt-guix-search-paths.patch, the
> search paths only take into account the user's home directory and the
> value of GUIX_PROFILE.
> 
> Doing `guix shell xcalc`, followed by `GUIX_PROFILE="$GUIX_ENVIRONMENT"
> xcalc` works for me.  It should work when installed in the default Guix
> profile, but this is pretty ugly.
> 
> This should also be the case for all libxt applications.

Ah, thanks for investigating. I confirm it works fine when installed
into my profile.

> WDYT?

Hm, I'd have to think about how to improve it. What do people think?

bug#50493: Update go-build-system to use Go 1.17.

[Leo Famulari]

On Wed, Dec 15, 2021 at 12:40:07PM +0200, Efraim Flashner wrote:
> I'll try poking it a bit with my aarch64 board. We can also switch the
> aarch64 go builds to bootstrap from gccgo, that might make a difference
> too.

Thanks, let us know how it goes.

I tried building go-1.17.4 for aarch64 with libgcc as an input, but it
failed in another way. So any progress you can make would be helpful.


signature.asc
Description: PGP signature

bug#50493: Update go-build-system to use Go 1.17.

[Efraim Flashner]

On Wed, Dec 15, 2021 at 12:44:05PM -0500, Leo Famulari wrote:
> On Wed, Dec 15, 2021 at 12:40:07PM +0200, Efraim Flashner wrote:
> > I'll try poking it a bit with my aarch64 board. We can also switch the
> > aarch64 go builds to bootstrap from gccgo, that might make a difference
> > too.
> 
> Thanks, let us know how it goes.
> 
> I tried building go-1.17.4 for aarch64 with libgcc as an input, but it
> failed in another way. So any progress you can make would be helpful.

I got pretty far commenting out binutils-gold and adding back in gcc:lib
and the substitute snippets. Then I started failing tests requiring the
linker, so it looks like I'll actually have to troubleshoot
binutils-gold.

I thought about trying gccgo in place of go-1.4 for the bootstrap, but
I'm pretty sure I'd still need binutils-gold.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#52517: inconstency with offloading

[zimoun]

Hi,

The manual provides [1] the example:

--8<---cut here---start->8---
  (build-machine
(name "armeight.example.org")
(systems (list "aarch64-linux"))
(host-key "ssh-rsa B3Nza…")
(user "alice")
(private-key
 (string-append (getenv "HOME")
"/.ssh/identity-for-guix")))
--8<---cut here---end--->8---

but what is not clear is 'getenv' from who.  Concretly, adding 'pk' it
reads:

--8<---cut here---start->8---
$ guix offload test

;;; ("/home/simon")
guix offload: testing 2 build machines defined in '/etc/guix/machines.scm'...
--8<---cut here---end--->8---

however, when really building with offload:

--8<---cut here---start->8---
$ guix build -L /tmp/mine r-cipr
The following derivation will be built:
   /gnu/store/mzixy5hhx79xx33k03acaasml87c0knc-r-cipr-0.1.0-1.4b01bb8.drv

;;; ("/root")
process 6815 acquired build slot '/var/guix/offload/x.x.x.x:22/0'
process 6815 acquired build slot '/var/guix/offload/x.x.x.x:22/0'
normalized load on machine 'x.x.x.x' is 0.00
--8<---cut here---end--->8---


"guix offload tes" does the correct thing, not "guix build".


Cheers,
simon


1: 

bug#52511: service networking provided more than once

[Mathieu Othacehe]

Hey,

> In this particular case, you could/should have a single
> ‘static-networking’ with multiple addresses:
>
>   (static-networking
> (addresses
>   (list (network-address …)
> (network-address …)))
> (routes …))

Oh, I see. There's still something problematic:

--8<---cut here---start->8---
;; Connection to the DMZ for public access
;; This is a 10G port.
(static-networking-service "eno2"
   "141.80.181.40"
   #:netmask "255.255.255.0"
   #:gateway "141.80.181.1")
;; Connection to build nodes
(static-networking-service "eno1"
   "141.80.167.131"
   #:netmask "255.255.255.192")
--8<---cut here---end--->8---

The above configuration used to create two distinct shepherd services:
networking-eno1 and networking-eno2.

We now have the aforementioned error because those two interfaces are
now provisioning 'networking, breaking compatibility.

Browsing the code, I also found:

--8<---cut here---start->8---
(service static-networking-service-type
 (list %loopback-static-networking

   ;; QEMU user-mode networking.  To get "eth0", you need
   ;; QEMU to emulate a device for which Mach has an
   ;; in-kernel driver, for instance with:
   ;; --device rtl8139,netdev=net0 --netdev user,id=net0
   %qemu-static-networking))
--8<---cut here---end--->8---

which made me think that creating a distinct static-networking record
per interface was the way to go.

Thanks,

Mathieu

bug#52510: guix install - profile build takes forever

[Ludovic Courtès]

Hi Florian,

Florian Hoertlehner  skribis:

> I use guix 1.3, and a simple guix install takes forever. It hangs 2-10
> minutes in the profile build phase.
> I have a NVME drive, and see 10-80 MB/sec IO Write in this timeframe.
>
> In the terminal I see: "building profile with 159 packages..."
> Then I have to wait 5 minutes.

So it’s really this “building profile” part that takes 5mn, right?

Could you share the output of ‘guix package --export-manifest’ (or ‘guix
package -I’)?  You can share it privately if you prefer not to make it
public.

On a 5yo SSD, and with 300+ packages in my profile, this part usually
takes a few seconds.  But it could be that for some packages, in
particular packages with lots of propagated inputs, this operation takes
longer.

Thanks,
Ludo’.

bug#52510: guix install - profile build takes forever

[Florian Hoertlehner]

I use guix 1.3, and a simple guix install takes forever. It hangs 2-10
minutes in the profile build phase.
I have a NVME drive, and see 10-80 MB/sec IO Write in this timeframe.

In the terminal I see: "building profile with 159 packages..."
Then I have to wait 5 minutes.

I assume it hard-linking of packages because  I use ext4.

this behavior is machine specific. On the machines that are affected it
occurs pretty consistent. But there are exceptions; when I install
a very small new package, the build time sometimes is in the 30 second
range. But typically it takes 5 minutes.

bug#52513: php build failure

[Mathieu Othacehe]

Hello,

The php package test suite is failing this way on master:

--8<---cut here---start->8---
=

=
FAILED TEST SUMMARY
-
int openssl_x509_checkpurpose ( mixed $x509cert , int $purpose [, array $cainfo 
= array() [, string $untrustedfile ]] ) function 
[ext/openssl/tests/openssl_x509_checkpurpose_basic.phpt]
=

=
WARNED TEST SUMMARY
-
FPM: Buffered worker output decorated log with multiple continuous messages 
(stdout/stderr mixed) [sapi/fpm/tests/log-bwd-multiple-msgs-stdout-stderr.phpt] 
(warn: XFAIL section but test passes)
=

You may have found a problem in PHP.
This report can be automatically sent to the PHP QA team at
http://qa.php.net/reports and http://news.php.net/php.qa.reports
This gives us a better understanding of PHP's behavior.
If you don't want to send the report immediately you can choose
option "s" to save it.  You can then email it to qa-repo...@lists.php.net later.
Do you want to send this report now? [Yns]: 
Notice: Trying to access array offset on value of type bool in 
/tmp/guix-build-php-7.4.26.drv-0/php-7.4.26/run-tests.php on line 934

Please enter your email address.
(Your address will be mangled so that it will not go out on any
mailinglist in plain text): sh: line 1: autoconf: command not found

Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or 
service not known in /tmp/guix-build-php-7.4.26.drv-0/php-7.4.26/run-tests.php 
on line 1133

Warning: fsockopen(): unable to connect to qa.php.net:80 
(php_network_getaddresses: getaddrinfo failed: Name or service not known) in 
/tmp/guix-build-php-7.4.26.drv-0/php-7.4.26/run-tests.php on line 1133

The test script was unable to automatically send the report to PHP's QA Team
Please send 
/tmp/guix-build-php-7.4.26.drv-0/php-7.4.26/php_test_results_20211215_1332.txt 
to qa-repo...@lists.php.net manually, thank you.
make: *** [Makefile:238: test] Error 1

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("test" "-j" "32") 
exit-status: 2 term-signal: #f stop-signal: #f> 
phase `check' failed after 971.4 seconds
command "make" "test" "-j" "32" failed with status 2
builder for `/gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv' failed 
with exit code 1
@ build-failed /gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv - 1 
builder for `/gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv' failed 
with exit code 1
derivation '/gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv' 
offloaded to '10.0.0.1' failed: build of 
`/gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv' failed
build of /gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv failed
View build log at 
'/var/log/guix/drvs/qv/gr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv.bz2'.
guix build: error: build of 
`/gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv' failed
--8<---cut here---end--->8---

The openssl_x509_checkpurpose test seems to blame.

Thanks,

Mathieu

bug#52333: [PATCH] Remove extraneous references

[Ricardo Wurmus]

I applied the change to r-minimal and discarded the other one.

-- 
Ricardo

bug#52511: service networking provided more than once

[Ludovic Courtès]

Hi!

Mathieu Othacehe  skribis:

> When using this service:
>
> (service static-networking-service-type
>   (list (static-networking
>  (addresses
>   (list
>;; Connection to the DMZ for public access
>;; This is a 10G port.
>(network-address
> (device "eno2")
> (value "141.80.181.40/24"
>  (routes
>   (list (network-route
>  (destination "default")
>  (gateway "141.80.181.1")
> (static-networking
>  (addresses
>   (list
>;; Connection to build nodes
>(network-address
> (device "eno1")
> (value "141.80.167.131/26")))
>
>
> I have the following error message:
>
> service networking provided more that once
>
> I guess it boils down to tweak the "provision" field accordingly, but it
> should be automated or documented properly.

In this particular case, you could/should have a single
‘static-networking’ with multiple addresses:

  (static-networking
(addresses
  (list (network-address …)
(network-address …)))
(routes …))

I’m not sure if there are other situations where this limitation is
problematic.

WDYT?

Thanks,
Ludo’.

bug#52511: service networking provided more than once

[Mathieu Othacehe]

Hello,

When using this service:

--8<---cut here---start->8---
(service static-networking-service-type
  (list (static-networking
 (addresses
  (list
   ;; Connection to the DMZ for public access
   ;; This is a 10G port.
   (network-address
(device "eno2")
(value "141.80.181.40/24"
 (routes
  (list (network-route
 (destination "default")
 (gateway "141.80.181.1")
(static-networking
 (addresses
  (list
   ;; Connection to build nodes
   (network-address
(device "eno1")
(value "141.80.167.131/26")))
--8<---cut here---end--->8---

I have the following error message:

--8<---cut here---start->8---
service networking provided more that once
--8<---cut here---end--->8---

I guess it boils down to tweak the "provision" field accordingly, but it
should be automated or documented properly.

Thanks,

Mathieu

bug#50493: Update go-build-system to use Go 1.17.

[Efraim Flashner]

On Tue, Dec 14, 2021 at 03:11:04PM -0500, Leo Famulari wrote:
> Alright, it's time to land these patches. I tested with a handful of
> packages on x86_64 and it seems fine. I can test every package before
> pushing.
> 
> However, Go 1.17.4 doesn't build for us on aarch64. I tried building the
> derivation for this scheduled CI job:
> 
> https://ci.guix.gnu.org/build/1952348/details
> /gnu/store/bldlnwxjwbi1iidm6cdw20kkpgy5gk09-go-1.17.4.drv

The link shows problems with the armhf portion of the bootstrap.

> And it fails the test suite due to missing libgcc (I think), or maybe
> something related to 'hello.exe', which seems weird:
> 
> --
> $ guix build /gnu/store/bldlnwxjwbi1iidm6cdw20kkpgy5gk09-go-1.17.4.drv
> [...]
> --- FAIL: TestTrampolineCgo (78.58s)
> link_test.go:739: executable failed to run: exit status 127
> 
> /tmp/guix-build-go-1.17.4.drv-0/TestTrampolineCgo602252092/001/hello.exe: 
> error while loading shared libraries: libgcc_s.so.1: cannot open shared 
> object file: No such file or directory
> link_test.go:742: unexpected output:
> 
> /tmp/guix-build-go-1.17.4.drv-0/TestTrampolineCgo602252092/001/hello.exe: 
> error while loading shared libraries: libgcc_s.so.1: cannot open shared 
> object file: No such file or directory
> FAIL
> FAILcmd/link425.553s
> ok  cmd/link/internal/benchmark 0.449s
> ok  cmd/link/internal/ld84.727s
> ok  cmd/link/internal/loader0.366s
> ok  cmd/nm  73.342s
> ok  cmd/objdump 96.072s
> ok  cmd/pack77.197s
> ok  cmd/pprof   155.165s
> ok  cmd/trace   2.437s
> ok  cmd/vet 318.126s
> FAIL
> go tool dist: Failed: exit status 1
> command "sh" "run.bash" "--no-rebuild" failed with status 1
> builder for `/gnu/store/bldlnwxjwbi1iidm6cdw20kkpgy5gk09-go-1.17.4.drv' 
> failed with exit code 1
> --
> 
> I notice that we remove libgcc from the dependencies of go-1.17:
> 
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/golang.scm?id=b484301f529e246df80380a641822f09a8775755#n799
> 
> Anyways, any ideas?

I'll try poking it a bit with my aarch64 board. We can also switch the
aarch64 go builds to bootstrap from gccgo, that might make a difference
too.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#52076: [core-updates-frozen] eigen-for-tensorflow fails to build

[Guillaume Le Vaillant]

Fixed on master branch (after core-updates-frozen merge).
Closing.


signature.asc
Description: PGP signature

bug#52501: xcalc seems broken

[Josselin Poiret via Bug reports for GNU Guix]

Leo Famulari  writes:

> Our xcalc package launches something that I can't figure out how to use.
> This is with Guix on Debian.
>
> Can anyone reproduce it?

I can reproduce it just fine using `guix shell xcalc -- xcalc`.  The
issue is that the application is styled using a resource file, in
./lib/X11/app-defaults/, which is supposed to be loaded by libxt.
Looking at gnu/packages/patches/libxt-guix-search-paths.patch, the
search paths only take into account the user's home directory and the
value of GUIX_PROFILE.

Doing `guix shell xcalc`, followed by `GUIX_PROFILE="$GUIX_ENVIRONMENT"
xcalc` works for me.  It should work when installed in the default Guix
profile, but this is pretty ugly.

This should also be the case for all libxt applications.

WDYT?

Best,
Josselin Poiret