bug#35279: emacs-xwidget does not provide support for xwidgets

[Maxim Cournoyer]

Hello,

m...@rohleder.de writes:

> Tim Gesthuizen  writes:
>> The section `Building Emacs with the '--with-xwidgets' option now
>> requires WebKit2.` from the Emacs 26.2 news indicates that we probably
>> just need to update to WebKit2 to fix the problem.
>
> this seems to be the case:
>
> $ guix environment -C bash --ad-hoc emacs-xwidget
> [env]$ ldd $(readlink -f $(type -p emacs)) |grep webkit
>   libwebkit2gtk-4.0.so.37 => 
> /gnu/store/3qfw8flc5rd063pz7m30g77zc9sacphf-webkitgtk-2.26.4/lib/libwebkit2gtk-4.0.so.37
>  (0x7f59243ea000)
>   libjavascriptcoregtk-4.0.so.18 => 
> /gnu/store/3qfw8flc5rd063pz7m30g77zc9sacphf-webkitgtk-2.26.4/lib/libjavascriptcoregtk-4.0.so.18
>  (0x7f5922f04000)
>
> $ guix environment -C bash --ad-hoc emacs
> [env]$ ldd $(readlink -f $(type -p emacs)) |grep webkit
>   => nothing
>
>
> so, I think this can be closed.

--8<---cut here---start->8---
$ guix build emacs-xwidgets --log-file --no-grafts
https://ci.guix.gnu.org/log/wp8542s2sagm170lskyiq1z96zp5y3gg-emacs-xwidgets-27.1
--8<---cut here---end--->8---

--8<---cut here---start->8---
$ wget 
https://ci.guix.gnu.org/log/wp8542s2sagm170lskyiq1z96zp5y3gg-emacs-xwidgets-27.1
 \
-O- | zgrep 'support Xwidgets'
Does Emacs support Xwidgets (requires gtk3)?yes
--8<---cut here---end--->8---

Closing :-).

Maxim

bug#42259: emacs-ess 18.10.2 sets R_HOME to a ridiculous value by default

[Maxim Cournoyer]

Hello,

Kyle Andrews  writes:

> I have been noticing many warnings coming from R in several contexts
> saying:
>
>   WARNING: ignoring environment value of R_HOME
>
> See for example the output of running:
>
>   $ R --version
>
> This warning appears to be coming from line 69 of ess-r-gui.el where an
> unset environment variable R_HOME is being set in elisp code which is
> pointing to some ancient version of R located inside a Microsoft Windows
> file system:
>
> R_HOME="c:/progra~1/R/R-2.6.1"
>
> This whole ess-r-gui.el file seems to be dedicated to interfacing with
> software in Microsoft Windows which doesn't seem at all relevant in the
> Guix world. This whole file can probably be safely deleted along with
> line 164 in the ESS/lisp/Makefile which I think triggers byte
> compilation.

This should be fixed in commit 0939462e3f81bc98b38bdb7610e6a80ca1cbaa1b.

Closing.  Thanks for the report!

Maxim

bug#43093: [PATCH] gnu: emacs-ess: Update to 20200903.1516.

[Maxim Cournoyer]

Hello!

Tim Howes  writes:

> * gnu/packages/statistics.scm (emacs-ess): Update to 20200903.1516.
> [version]: Use latest commit, assign version based on commit date.
> [source]: Fix snippet for removing julia-mode.  Remove snippet to modify
> roxy-preview-Rd-test.  Add snippet to modify r-help-mode test.  Add
> snippet to fix install target to install files to correct directories.
> [arguments]: Add flag to specify INFODIR.  Remove patch modifying SHELL.
> ---
> This updates emacs-ess to the current version on github and resolves
> bugs #43093 and #42259.

I'm closing this bug, since a more current patch was merged to master
[0] about two days ago, which resolves the issue.

Thank you!

Maxim

[0]  https://issues.guix.gnu.org/43208#11

bug#40144: --rounds has no effect when used in conjunction with --check

[Maxim Cournoyer]

Hello Brice,

Brice Waegeneire  writes:

> Hello,
>
> Since this bug is already known[0] this report is just to keep of it.
>
> guix --check --rounds=3 hello only build the package once instead of
> three time.
>
> [0]: http://logs.guix.gnu.org/guix/2020-03-18.log#213921
>
> Brice.

Thanks for logging this as a bug, it's an annoying one that we should
fix.  In the logs posted above, Ludovic mentioned "this is happening in
the daemon, taken from Nix", when talking about the behavior of --rounds
not being honored when --check is given.

I'll try having a look,

Maxim

bug#43243: emacs-elfeed-org, mapc: Symbol’s function definition is void

[Maxim Cournoyer]

Hello Giovanni,

Giovanni Biscuolo  writes:

> Giovanni Biscuolo  writes:
>
>> I use emacs-elfeed-org to organize my feeds for emacs--elfeed.
>>
>> After my last upgrade to Emacs 27.1 I get this error in the Messages
>> buffer when I try to "M-x elfeed":
>
> [...]
>
> I've filed an issue upstream:
> https://github.com/remyhonig/elfeed-org/issues/56

I tried to reproduce this using the following environment:

--8<---cut here---start->8---
guix environment --pure --ad-hoc emacs emacs-elfeed
--8<---cut here---end--->8---

Then launching emacs with 'emacs -q', and running elfeed with M-x
elfeed, and couldn't reproduce the problem.

Are you using a different flavor of Emacs, or just the 'emacs' Guix
package? emacs-next's search path is currently broken, for example.

Thanks,

Maxim

bug#41732: New ’package-with-emacs-next’ procedure

[Maxim Cournoyer]

Hello,

Nicolas Goaziou  writes:

> Possibly. And then Magit uses emacs-no-x as an input, so we may need to
> also add --with-input=emacs-no-x=emacs-next to the command.
>
> I'm just pointing out that the process is not as straightforward as it
> might seem. So, it doesn't sound right to simply suggest
>
>   guix build -m manifest.scm --with-input=emacs-minimal=emacs-next
>
> in the manual/cookbook without caution.
>
> Or maybe `package-with-emacs-next' could be more high-level, and handle
> all of these cases. I don't know.

Yeah, that would probably me more convenient/robust to use, if it was
covering for all the weird cases one might forget.  I'd still be in
favor of having such a helper procedure.

Maxim

bug#43662: 'guix refresh' can hang during interactions with FTP servers

[Maxim Cournoyer]

Hello,

Running 'guix refresh gnutls' on master hangs, with no output.

Strace suggests that the hang originates from the code attempting to
fetch what's in the GNU FTP server:

[pid 19343] close(17)   = 0
[pid 19343] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 17
[pid 19343] connect(17, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 
110) = 0
[pid 19343] sendto(17, "\2\0\0\0\16\0\0\0\17\0\0\0ftp.gnutls.org\0", 27, 
MSG_NOSIGNAL, NULL, 0) = 27
[pid 19343] poll([{fd=17, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1 
([{fd=17, revents=POLLIN}])
[pid 19343] read(17, "\2\0\0\0\1\0\0\0\1\0\0\0\4\0\0\0\16\0\0\0\0\0\0\0", 24) = 
24
[pid 19343] read(17, "\331EL7\2ftp.gnupg.org\0", 19) = 19
[pid 19343] close(17)   = 0
[pid 19343] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 17
[pid 19343] connect(17, {sa_family=AF_INET, sin_port=htons(21), 
sin_addr=inet_addr("217.69.76.55")}, 16) = 0
[pid 19343] fstat(17, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
[pid 19343] read(17, "220-Welcome hacker!\r\n", 4096) = 21
[pid 19343] read(17, "220-.\r\n220-This is the FTP server of the GnuPG project. 
 If you are looking for\r\n220-GnuPG change to the \"gcrypt\" directory.  
Please send problem reports\r\n220-to ftpmas...@gnupg.org after having checked 
the gnupg-users archives\r\n220-at 
https://lists.gnupg.org/pipermail/gnupg-users/ for known problems."..., 4096) = 
680
[pid 19343] write(17, "USER anonymous\r\n", 16) = 16
[pid 19343] read(17, "331 Send e-mail address as password.\r\n", 4096) = 38
[pid 19343] write(17, "PASS g...@example.com\r\n", 23) = 23
[pid 19343] read(17, "230 User logged in, proceed.\r\n", 4096) = 30
[pid 19343] write(17, "CWD /\r\n", 7)   = 7
[pid 19343] read(17, "250 Directory change successful.\r\n", 4096) = 34
[pid 19343] write(17, "CWD gcrypt\r\n", 12) = 12
[pid 19343] read(17, "250-This directory is used as FTP site for GNU crypto 
software and\r\n250-related stuff.\r\n250-.\r\n250-US laws place restrictions 
on the export of defense articles, which\r\n250-includes some types of 
cryptographic software; this is the reason\r\n250-that such software is not 
available from ftp.gnu.org. It is"..., 4096) = 1106
[pid 19343] write(17, "CWD gnutls\r\n", 12) = 12
[pid 19343] read(17, "250-More information on GnuTLS can be found at 
http://www.gnutls.org/\r\n250 Directory change successful.\r\n", 4096) = 105
[pid 19343] write(17, "PASV\r\n", 6)= 6
[pid 19343] read(17,

Maxim

bug#43661: [mumi] Patch series appear incomplete when viewed with MUMI

[Maxim Cournoyer]

Hello,

I noticed this problem with the issue #43627, a 3 items patch series
sent recently: https://issues.guix.gnu.org/43627.

The patch 1/3 appears to be missing when viewed at the MUMI-powered link
above.  Debbugs doesn't have this issue: https://bugs.gnu.org/43627.

Thanks,

Maxim

bug#43660: icedove: "guix build --source" should produce IceDove source

[Mark H Weaver]

At present, "guix build --source icedove" simply returns the
corresponding IceCat tarball.  The addition of code from upstream
Thunderbird, as well as the rebranding to "IceDove", is currently done
within phases.

It would be good to arrange for "guix build --source icedove" to return
something more appropriate.

I suggest that the first step should add an 'icedove-source' variable
that produces an icedove tarball, for now implemented in a way similar
to 'icecat-source' and incorporating the functionality of the
'prepare-thunderbird-sources' and 'rename-to-icedove' phases of the
'icedove' package.

Note that snippets are unable to do this job, because they are only able
to produce tarballs with the same file name and top-level directory name
as the main upstream input.  In this case, we need to produce a tarball
with name and top-level directory 'icedove' starting from an 'icecat'
tarball.

   Mark

bug#43658: Implement HandleLidSwitchExternalPower setting

[Nathan Dehnel]

This
https://github.com/elogind/elogind/blob/8e778a23e1c13bd3613c9c40a53291d476ae8c2a/src/login/logind.conf.in
seems to indicate that elogind supports HandleLidSwitchExternalPower.

This https://guix.gnu.org/manual/en/html_node/Desktop-Services.html seems
to indicate that guix does not support that setting.

bug#38100: ‘--with-input’ causes unintended rebuilds

[Ludovic Courtès]

Hey there!

Ludovic Courtès  skribis:

> Ludovic Courtès  skribis:
>
>> Indeed, evaluating:
>>
>>   (bag-transitive-inputs
>>(package->bag ((package-input-rewriting '()) glib)))
>>
>> shows that we have two “python” packages there that are not ‘eq?’.
>
> The problem is that ‘glib’ depends on ‘python-libxml2’, which uses
> ‘python-build-system’ and thus has ‘python’ as an implicit input.
>
> ‘package-input-rewriting’ doesn’t touch implicit inputs so it leaves
> that implicit ‘python’ untouched.
>
> Since ‘transitive-inputs’ (used by ‘bag-transitive-inputs’) uses pointer
> equality, we end up with two “python” packages that are not ‘eq?’ but
> are functionally equivalent: the one produced by
> ‘package-input-rewriting’, and the implicit dependency of
> ‘python-libxml2’.  QED.
>
> (This is essentially the same as .)

Good news, this is fixed by 2bf6f962b91123b0474c0f7123cd17efe7f09a66,
which introduces package rewriting including implicit inputs!

Before getting there, this issue did get on my nerves for a while.  Here
are several ways to address this issue that I thought of:

  1. Have ‘package-input-rewriting/spec’ traverse implicit inputs, at
 least optionally.  We wouldn’t end up with an
 equivalent-but-not-eq? ‘python’ in the example above.  It does
 change the semantics though, and it may be nice to keep a “shallow”
 replacement option.  That’s what
 2bf6f962b91123b0474c0f7123cd17efe7f09a66 does.

  2. Do (delete-duplicates input-drvs) in ‘bag->derivation’.  That seems
 wise, but it’s unfortunately impossible on ‘master’ because of
 .

  3. ‘package-input-rewriting/spec’ preserves eq?-ness for packages not
 transformed; in the example above, the transformation result would
 be eq? to ‘glib’ because ‘--with-input=libreoffice=inkscape’ had no
 effect.  Tricky to implement efficiently, perhaps not worth it.

I think #2 might still be worth investigating, but it may have
undesirable implications too.  #3 is hardly doable.

All in all, I’m glad that #1 addresses the issue, because it’s also
something we wanted anyway.

Ludo’.

bug#43643: start shepherd when a previous instance was killed by kill -9

[gfleury]

hello,

27 septembre 2020 16:29 "Danny Milosavljevic"  a écrit:

> Hello,
> 
> On Sun, 27 Sep 2020 10:00:03 +0200
> gfleury  wrote:
> 
>> it throws a error:
>> -
>> 3 (primitive-load "/home/gfleury/prod/shepherd/./shepherd")
>> In shepherd.scm:
>> 56:14 2 (main . _)
>> 49:6 1 (open-server-socket _)
>> In unknown file:
>> 0 (bind # #(1 "/run/user/1000?") #)
>> 
>> ERROR: In procedure bind:
>> In procedure bind: Address already in use
>> -
>> 
>> something like this patch can fix it.
> 
> Please don't do it that way.
> 
> Shepherd has to be able to ascertain that it is not running yet before
> starting yet another instance in parallel.
> 
i missed that part.

> I don't like PID and socket files either--but it's just what we have
> available.
> 
> Maybe find out who is at the other side of the socket
> (connect and then use getpeername on the socket or something ?
> maybe even just trying to connect fails, which would be good for this).
> 
> I think UNIX domain sockets are made in a way that it doesn't matter
> whether the server or the client connects first, so even that would
> probably not be reliable.
> 
> So maybe just live with having to remove the socket file yourself.
> 
> I'm open to other suggestions that are safe that accomplish the same goal.

yes a better solution is needed.

bug#35589: Scribus and GIMP: Clipped, non-resizable windows and pixelated icons

[sirgazil via Bug reports for GNU Guix]

This issue fixed itself, I can't reproduce it anymore in guix 97e98e2.

bug#36100: Jami leaks memory

[sirgazil via Bug reports for GNU Guix]

I'm closing this issue because the package the report was filed against was 
removed from Guix:

gnu: jami-client-gnome: Remove deprecated package.
commit 8551bc64e4322080ef07b5009f4d46229df8d6f3
Date:   Sun Jul 12 18:00:46 2020 +0200

Also, there is a new package for Jami that I tried out:

Guix System 97e98e2
Jami 20200710.1.6bd18d2

I followed the steps below to try reproduce the issue with this new version and 
I could not see any memory leak.

1. $ guix install jami
2. Press Alt+F2 and run "jami"
2.1. Create a Jami account
3. Press Alt+F2 and run "gnome-system-monitor"
4. Click on "Processes"
5. Locate the "jami" process
6. Observe the "Memory" use for a few hours

Problem solved.

bug#43629: Cross-compiled guile-lzlib unusable, causing ‘guix substitute’ to crash on GNU/Hurd

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe  skribis:

>> checking dependency style of i586-pc-gnu-gcc... none
>> checking lzlib's file name... 
>
> Oh, I guess the same goes for guile-zlib and all cross-compilation
> targets. I'll have a look later on.

Fixed in Guile-lzlib here:

  
https://notabug.org/guile-lzlib/guile-lzlib/commit/82576e34b4870b8977e131a40831219f8c1ea521

Guile-zlib doesn’t have this problem because it uses pkg-config to
determine LIBZ_LIBDIR.

When you feel like it, we can have a .2 release of Guile-lzlib with this
fix.

Thanks,
Ludo’.

bug#43610: IceCat segfault

[Mark H Weaver]

Hi,

raingloom  writes:

> On Sat, 26 Sep 2020 14:05:53 -0400
> Mark H Weaver  wrote:
>
>> In the meantime, to start IceCat 78 with your existing profile but
>> with addons temporarily disabled, try running:
>> 
>>   icecat -safe-mode
>> 
>> That should allow you to recover your existing bookmarks, history,
>> cookies, saved passwords, tabs, etc.  Then you can try adding back
>> your preferred addons incrementally to find out which one is causing
>> the problem.
>
> It still crashes with the -safe-mode flag. Luckily I keep most things
> outside modern browsers, so it's not a huge loss. (For obvious reasons
> I do not consider them reliable.)

If you'd like to try another experiment, it would be interesting to know
if you're able to recover most of your old profile by running "icecat
-safe-mode -p", selecting your old profile, and clicking on the "Refresh
IceCat" button that is presented.  That will reset all preferences to
the IceCat defaults, but might enable you to recover the things I listed
above.

>> > Tbh this would be a good time to have a debug output for IceCat on
>> > hand.  
>> 
>> While I acknowledge that it might occasionally be useful in edge cases
>> like this, it would also dramatically increase the memory requirements
>> at build time. [...]
>
> Huh, I was not aware that it increased build time memory requirements.
> I assumed it just gets sent to the void in the 'strip phase, just like
> it is in other packages.

We currently pass "--disable-debug" and "--disable-debug-symbols" to
IceCat's configure script, which causes it to pass compiler flags that
disable generation of debug symbols during the build.

> As a fellow 4 gigger/thinkpadder I
> appreciate anything that lets me build things locally without 16+ gigs
> of swap. (you might think that's an exaggeration, but then you haven't
> tried to build Idris 2 with Idris 1.)

I've actually tried (and failed) to build Idris 1 locally, so I can
sympathize :-/

   Mark

bug#43500: qemu-minimal test suite crashes on armhf-linux, aarch64-linux

[Maxim Cournoyer]

retitle 43500 qemu-minimal test suite crashes on armhf-linux, aarch64-linux
quit

Maxim Cournoyer  writes:

> Running the following commands on the current master branch (commit
> 679d5e6b3dcac4ee1f419c04b3719fead0bd9ee5):
>
> ./pre-inst-env guix build qemu-minimal --rounds=5 --system=armhf-linux
>
>
> Produces the following error during the test suite:
>
> PASS 26 qos-test 
> /arm/virt/virtio-mmio/virtio-bus/virtio-blk-device/virtio-blk/virtio-blk-tests/config
> PASS 27 qos-test 
> /arm/virt/virtio-mmio/virtio-bus/virtio-blk-device/virtio-blk/virtio-blk-tests/basic
> PASS 28 qos-test 
> /arm/virt/virtio-mmio/virtio-bus/virtio-blk-device/virtio-blk/virtio-blk-tests/resize
> PASS 29 qos-test 
> /arm/virt/virtio-mmio/virtio-bus/virtio-net-device/virtio-net/virtio-net-tests/basic
> PASS 30 qos-test 
> /arm/virt/virtio-mmio/virtio-bus/virtio-net-device/virtio-net/virtio-net-tests/rx_stop_cont
> PASS 31 qos-test 
> /arm/virt/virtio-mmio/virtio-bus/virtio-net-device/virtio-net/virtio-net-tests/announce-self
> **
> ERROR:tests/qtest/qos-test.c:175:subprocess_run_one_test: child process 
> (/arm/virt/virtio-mmio/virtio-bus/virtio-net-device/virtio-net/virtio-net-tests/vhost-user/migrate/subprocess
>  [28290]) failed unexpectedly
> ERROR - Bail out! ERROR:tests/qtest/qos-test.c:175:subprocess_run_one_test: 
> child process 
> (/arm/virt/virtio-mmio/virtio-bus/virtio-net-device/virtio-net/virtio-net-tests/vhost-user/migrate/subprocess
>  [28290]) failed unexpectedly
> qemu: uncaught target signal 6 (Aborted) - core dumped
> make: *** 
> [/tmp/guix-build-qemu-minimal-5.0.0.drv-0/qemu-5.0.0/tests/Makefile.include:636:
>  check-qtest-arm] Error 1
>
> Test suite failed, dumping logs.
> command "make" "check" "V=1" failed with status 2
> builder for 
> `/gnu/store/8acnk9shp48ppd75q9sbih49gz5m2wgb-qemu-minimal-5.0.0.drv' failed 
> with exit code 1
> @ build-failed 
> /gnu/store/8acnk9shp48ppd75q9sbih49gz5m2wgb-qemu-minimal-5.0.0.drv - 1 
> builder for 
> `/gnu/store/8acnk9shp48ppd75q9sbih49gz5m2wgb-qemu-minimal-5.0.0.drv' failed 
> with exit code 1

The same occurs using aarch64-linux:

PASS 63 qom-test /aarch64/qom/connex
**
ERROR:tests/qtest/qos-test.c:186:subprocess_run_one_test: child process 
(/arm/virt/virtio-mmio/virtio-bus/virtio-net-device/virtio-net/virtio-net-tests/vhost-user/migrate/subprocess
 [22042]) failed unexpectedly
ERROR qos-test - Bail out! 
ERROR:tests/qtest/qos-test.c:186:subprocess_run_one_test: child process 
(/arm/virt/virtio-mmio/virtio-bus/virtio-net-device/virtio-net/virtio-net-tests/vhost-user/migrate/subprocess
 [22042]) failed unexpectedly
qemu: uncaught target signal 6 (Aborted) - core dumped
make: *** 
[/tmp/guix-build-qemu-minimal-5.1.0.drv-0/qemu-5.1.0/tests/Makefile.include:650:
 check-qtest-arm] Error 1
make: *** Waiting for unfinished jobs

bug#25227: [Website] Package-related pages redesign proposal

[sirgazil via Bug reports for GNU Guix]

Closing this, since guix.gnu.org is available for several months now.

bug#43643: start shepherd when a previous instance was killed by kill -9

[Danny Milosavljevic]

Hello,

On Sun, 27 Sep 2020 10:00:03 +0200
gfleury  wrote:

> it throws a error:
> -
> 3 (primitive-load "/home/gfleury/prod/shepherd/./shepherd")
> In shepherd.scm:
> 56:14  2 (main . _)
>  49:6  1 (open-server-socket _)
> In unknown file:
>0 (bind # #(1 "/run/user/1000?") #)
> 
> ERROR: In procedure bind:
> In procedure bind: Address already in use
> -
> 
> something like this patch can fix it.

Please don't do it that way.

Shepherd has to be able to ascertain that it is not running yet before
starting yet another instance in parallel.

I don't like PID and socket files either--but it's just what we have
available.

Maybe find out who is at the other side of the socket
(connect and then use getpeername on the socket or something ?
 maybe even just trying to connect fails, which would be good for this).

I think UNIX domain sockets are made in a way that it doesn't matter
whether the server or the client connects first, so even that would
probably not be reliable.

So maybe just live with having to remove the socket file yourself.

I'm open to other suggestions that are safe that accomplish the same goal.


pgp4yu_ufOMXZ.pgp
Description: OpenPGP digital signature

bug#36951: guile-sly will not build

[Jesse Gibbons]

I just checked this, it seems to have been fixed.

bug#37190: rhythmbox cannot subscribe to any podcasts

[Jesse Gibbons]

I just checked this, it seems to have been fixed.

bug#43643: start shepherd when a previous instance was killed by kill -9

[gfleury]

Hi,

when killing shepherd i.e `pkill -9 shepherd` it left behind
`default-socket-file` and when restarted whithout remove the socket like
-
rm /var/run/user/1000/shepherd/socket
-

it throws a error:
-
3 (primitive-load "/home/gfleury/prod/shepherd/./shepherd")
In shepherd.scm:
56:14  2 (main . _)
 49:6  1 (open-server-socket _)
In unknown file:
   0 (bind # #(1 "/run/user/1000?") #)

ERROR: In procedure bind:
In procedure bind: Address already in use
-

something like this patch can fix it.
>From 7d16c47bad6fd98cf0838d2fcd62735d846e7bab Mon Sep 17 00:00:00 2001
From: gfleury 
Date: Sun, 27 Sep 2020 09:29:37 +0200
Subject: [PATCH] ensure that `default-socket-file` is not present.

* modules/shepherd.scm(main): remove a possible `default-socket-file`
  left by a previous instance.
---
 modules/shepherd.scm | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/modules/shepherd.scm b/modules/shepherd.scm
index 9f80f62..d18567e 100644
--- a/modules/shepherd.scm
+++ b/modules/shepherd.scm
@@ -147,7 +147,10 @@ already ~a threads running, disabling 'signalfd' support")
   (initialize-cli)
 
   (let ((config-file #f)
-	(socket-file default-socket-file)
+	(socket-file
+ (begin
+   (false-if-exception (delete-file default-socket-file))
+   default-socket-file))
 (pid-file#f)
 (secure  #t)
 (logfile #f))
-- 
2.28.0

bug#41732: New ’package-with-emacs-next’ procedure

[Nicolas Goaziou]

Hello,

Maxim Cournoyer  writes:

> Perhaps then,
>
> --8<---cut here---start->8---
> guix build -m manifest.scm --with-input=emacs-minimal=emacs-next \
>  --with-input=emacs=emacs-next
> --8<---cut here---end--->8---

Possibly. And then Magit uses emacs-no-x as an input, so we may need to
also add --with-input=emacs-no-x=emacs-next to the command.

I'm just pointing out that the process is not as straightforward as it
might seem. So, it doesn't sound right to simply suggest

  guix build -m manifest.scm --with-input=emacs-minimal=emacs-next

in the manual/cookbook without caution.

Or maybe `package-with-emacs-next' could be more high-level, and handle
all of these cases. I don't know.

Regards,
-- 
Nicolas Goaziou

bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot

[Danny Milosavljevic]

Hmm, /home/dannym is missing there.  I can log in but not pull.


pgp84jG1Lx8Up.pgp
Description: OpenPGP digital signature

bug#43513: json-c build failure (on armhf-linux) while trying to build u-boot

[Andreas Enge]

Hello Danny,

On Sat, Sep 26, 2020 at 12:53:20PM +0200, Danny Milosavljevic wrote:
> I'd like to test what happens if one builds json-c on an aarch64 host
> for i686.
> Could we enable qemu-binfmt for i686 on an aarch64 host for me to test it?
> One machine is enough--I'd just run
>   guix environment -s i686-linux gcc-toolchain -- gcc -o a00 
> -D_FILE_OFFSET_BITS=xxx a00.c
> and then later
>   guix build -s i686-linux json-c

you can give it a try on dover.guix.info, but you should be ready for
a wait: As other build machines, it does not use substitutes, so everything
will be built locally using qemu-binfmt. Maybe you could import what
is needed for the "guix environment" from an i686 machine?

I would suggest to do a "guix pull 
--commit=0939462e3f81bc98b38bdb7610e6a80ca1cbaa1b",
since this is the version already available on the machine.

Andreas