bug#43579: g++ does not provide std::fegetround

[Brett Gilio]

Ludovic Courtès  writes:

> Hallo!
>
> Andreas Enge  skribis:
>
>> The following test file round.cpp does not compile with our g++-10.2.0:
>> #include 
>> int main () {
>>return std::fegetround ();
>> }
>
> Could you provide detailed steps to reproduce it?
>
> Thanks,
> Ludo’.

I believe `std::fegetround` was introduced in C++11, are you using the
appropriate flag?

Brett Gilio

bug#43738: Patch file names too long

[Brett Gilio]

Ludovic Courtès  writes:

> There are several patch file names that are too long for ‘tar’, as
> reported during ‘make dist’:
>
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/ocaml-bisect-fix-camlp4-in-another-directory.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/audiofile-signature-of-multiplyCheckOverflow.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/python2-pygobject-2-gi-info-type-error-domain.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/audiofile-division-by-zero-BlockCodec-runPull.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
> tar: 
> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/python-robotframework-honor-source-date-epoch.patch
>  dosiernomo tro longas (maks 99); ne ŝutita
>
> ‘guix lint’ reports it as well, but apparently this is easily
> overlooked.
>
> Ludo’.

Does it matter that this is coming from a dirty working tree? Maybe not.

Brett Gilio

bug#43610: IceCat segfault

[raingloom]

On Fri, 2 Oct 2020 00:57:39 +0200
raingloom  wrote:

> On Sun, 27 Sep 2020 16:36:52 -0400
> Mark H Weaver  wrote:
> 
> > 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.  
> 
> What I tried was running the old IceCat and disabling every single
> addon. It did not fix anything.
> Gonna see if my about:config modifications are messing something up.
> 
> I hate these "modern" (transl.: google approved) browsers so fricking
> much...

Well, what ended up working was deleting a bunch of file from the
profile directory. No idea which deletion made it work and at this
point I just wanna crawl back to Netsurf.
Can't say I'd recommend this workaround to regular users, but if you
can guess what those files are, you should be safe.

Files and directories I deleted: (taken from ~/.local/share/Trash/files)

```
{513646f8-fb87-4135-a41e-4cf1d1f2}
{74145f27-f039-47ce-a470-a662b129930a}
{9063c2e9-e07c-4c2c-9646-cfe7ca8d0498}
AlternateServices.2.txt
AlternateServices.txt
blocklist.xml
broadcast-listeners.json
{c2c003ee-bd69-42a2-b0e9-6f34222cb046}
{c607c8df-14a7-4f28-894f-29e8722976af}
cert_override.txt
compatibility.2.ini
compatibility.ini
containers.json
datareporting
{de89ec3b-0f2a-45af-aeec-931d16988f72}
{e4a8a97b-f2ed-450b-b12d-ee082ba24781}
enumerate_devices.txt
gmp
handlers.json
https-everywh...@eff.org
pkcs11.txt
prefs.js
SecurityPreloadState.txt
sessionCheckpoints.json
sessionstore.jsonlz4
shinigamieyes@shinigamieyes
SiteSecurityServiceState.txt
staged
storage.sqlite
storage-sync.sqlite
Telemetry.ShutdownTime.txt
times.json
TRRBlacklist.txt
wappaly...@crunchlabz.com
weave
```

bug#43610: IceCat segfault

[raingloom]

On Sun, 27 Sep 2020 16:36:52 -0400
Mark H Weaver  wrote:

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

What I tried was running the old IceCat and disabling every single
addon. It did not fix anything.
Gonna see if my about:config modifications are messing something up.

I hate these "modern" (transl.: google approved) browsers so fricking
much...

bug#43746: What to do about packages that don't support --without-tests / #:tests? #f setting

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> The new package transformation option --without-tests works by setting
> #:tests? #f in the specified packages.  But some packages replace
> their 'check phase and no longer honor #tests?.  glib for example.

Oh, we should fix ‘glib’ in ‘core-updates’.

> Attached is an attempt to document this current behavior.  Shall I
> push it?  Alternatively, it should be documented to write a check
> phase that honors #:tests?.  Or the package transformation should be
> changed to remove any check phase it finds.

Hmm not sure, I think fiddling with phases is more risky or at least
could lead to more obscure errors for example with build systems that
don’t support phases, like ‘trivial-build-system’.

I’m inclined to apply the patch you propose and leaving phases
unchanged.

>>From b55e6ee01fe674b282e7ec75d0e4c8a839262261 Mon Sep 17 00:00:00 2001
> From: Florian Pelz 
> Date: Thu, 1 Oct 2020 15:35:52 +0200
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> Subject: [PATCH] doc: Explain why '--without-tests' may fail with modified
>  'check' phase.
>
> * doc/guix.texi (Package Transformation Options): Explain.

[...]

> +Internally, @code{--without-tests} relies on changing the
> +@code{#:tests?} option of a package's @code{check} phase (@pxref{Build
> +Systems}).  Note that some packages use a customized @code{check} phase
> +that does not respect a @code{#:tests? #f} setting.  Therefore there are
> +some packages for which @code{--without-tests} cannot disable tests.

I’d change the last sentence to:

  Therefore, @option{--without-tests} has no effect on these packages.

Thanks,
Ludo’.

bug#43750: Utox fails to install

[Marinus Savoritias]

I tried to install Utox today and it fails with the following issue:

The corresponding part of the log:

In file included from 
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.c:33:0:
/gnu/store/aqidpw0zfj1sr6cbqqs27j5dj202cfkp-openal-1.20.1/include/AL/alc.h:34:26: 
error: conflicting types for ‘ALCdevice’

 typedef struct ALCdevice ALCdevice;
  ^
In file included from 
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.c:1:0:
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.h:8:33: note: 
previous declaration of ‘ALCdevice’ was here

 typedef struct ALCdevice_struct ALCdevice;
 ^
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.c:161:6: error: 
conflicting types for ‘utox_audio_in_device_set’

 bool utox_audio_in_device_set(ALCdevice *new_device) {
  ^~~~
In file included from 
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.c:1:0:
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.h:68:6: note: 
previous declaration of ‘utox_audio_in_device_set’ was here

 bool utox_audio_in_device_set(ALCdevice *new_device);
  ^~~~
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.c:178:12: error: 
conflicting types for ‘utox_audio_in_device_get’

 ALCdevice *utox_audio_in_device_get(void) {
^~~~
In file included from 
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.c:1:0:
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.h:70:12: note: 
previous declaration of ‘utox_audio_in_device_get’ was here

 ALCdevice *utox_audio_in_device_get(void);
^~~~
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.c:265:6: error: 
conflicting types for ‘utox_audio_out_device_set’

 bool utox_audio_out_device_set(ALCdevice *new_device) {
  ^
In file included from 
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.c:1:0:
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.h:69:6: note: 
previous declaration of ‘utox_audio_out_device_set’ was here

 bool utox_audio_out_device_set(ALCdevice *new_device);
  ^
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.c:278:12: error: 
conflicting types for ‘utox_audio_out_device_get’

 ALCdevice *utox_audio_out_device_get(void) {
^
In file included from 
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.c:1:0:
/tmp/guix-build-utox-0.17.1.drv-0/source/src/av/audio.h:72:12: note: 
previous declaration of ‘utox_audio_out_device_get’ was here

 ALCdevice *utox_audio_out_device_get(void);
^
make[2]: *** [src/av/CMakeFiles/utoxAV.dir/build.make:79: 
src/av/CMakeFiles/utoxAV.dir/audio.c.o] Error 1

make[2]: Leaving directory '/tmp/guix-build-utox-0.17.1.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:356: 
src/av/CMakeFiles/utoxAV.dir/all] Error 2

make[1]: Leaving directory '/tmp/guix-build-utox-0.17.1.drv-0/build'
make: *** [Makefile:166: all] Error 2
command "make" "-j" "1" failed with status 2

Marinus Savoritias

bug#39670: Cannot mount NFS share as user or root

[Maxim Cournoyer]

Hi!

> Nathan Dehnel  writes:
>
>> Right, but it's more inconvenient than just clicking the share in thunar
>> and it mounting. Actually, I can't mount it without doing "sudo" first,
>> despite having the "user" fstab flag set. This actually might be a separate
>> issue, but I'm not sure.
>
> That's a good point.  We should try to make this simpler.  The mount.nfs
> binary needs to be setuid root to allow unprivileged users to mount NFS
> file systems.  Unfortunately, the mount command (which we already define
> as setuid-root) only looked for helpers under /run/current/profile/sbin.
> This is now fixed in commit def6e2ae4619587114383b3f8fd9f3cf8310b4b9
> (which had to be made on core-updates).
>

[...]

> I've sent a patch for review which proposes to add these setuid-root binaries 
> for
> desktop users out-of-the-box on Guix System, which only adds about 4 MiB
> to the almost 3 GiB closure of the lightweight-desktop.tmpl system [0].
>
> As mentioned before, it depends on a change to util-linux that had to be
> made on the core-updates branch, so it won't be usable until the next
> core-updates merge.

This patch has now been merged with commit d40c9f6c85.

Closing!

Thank you,

Maxim

bug#43686: ocaml-sqlite3 build fails

[Maxim Cournoyer]

Hi,

Julien Lepiller  writes:

> Le Mon, 28 Sep 2020 23:06:18 -0400,
> Maxim Cournoyer  a écrit :
>
>> On current master, attempting to build ocaml-sqlite3 yields:
>> 
>> --8<---cut here---start->8---
>> starting phase `build'
>> File "src/config/discover.ml", line 1:
>> Error:
>> /gnu/store/1wwdmzcjhrpal92sz2zwzhyqmbc3w7ri-dune-1.11.3/lib/ocaml/site-lib/dune/configurator/configurator.cmi
>> is not a compiled interface for this version of OCaml. It seems to be
>> for a newer version of OCaml. command "dune" "build" "@install"
>> failed with status 1 builder for
>> `/gnu/store/66mbim7cc90f9ngh2pkm0kw192z5rb6y-ocaml4.07-sqlite3-4.4.1.drv'
>> failed with exit code 1 --8<---cut
>> here---end--->8---
>> 
>> 
>> 
>
> Hi, fixed with db194f714a8beb155c508c06e346c7c2322e7053.  You can run
> guix pull to get this version.

Thank you for the prompt resolution!

Maxim

bug#40116: GDM: Memory leak in .gnome-shell-real process

[Luis Felipe via Bug reports for GNU Guix]

I've been using GDM again for 8 days now, and I don't see the leak anymore.

(Using guix 97e98e2)

---
Luis Felipe López Acevedo
https://luis-felipe.gitlab.io/

bug#43739: guix archive --export broken on foreign distro

[Lars-Dominik Braun]

Hi,

as discussed on IRC [1][2] `guix archive --export` is currently broken on
foreign distributions. It fails with the error message:

guix archive: error: corrupt input while restoring archive from 
#

strace reveals `guix authenticate` prints a message to stderr, which the
guix-daemon does not expect:

guile: warning: failed to install locale

Installing the package glibc-locales into root’s user profile (because
guix-daemon.service references that) and restarting the daemon solves the
issue.

See also https://issues.guix.gnu.org/43737

Cheers,
Lars

[1] http://logs.guix.gnu.org/guix/2020-09-29.log#141931
[2] http://logs.guix.gnu.org/guix/2020-09-30.log#113955


signature.asc
Description: PGP signature

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

[Bengt Richter]

Hi,

On +2020-09-30 14:17:31 +0200, Andreas Enge wrote:
> Hello,
> 
> On Wed, Sep 30, 2020 at 01:27:54PM +0200, Danny Milosavljevic wrote:
> > At least I don't.  I don't even have a homedir on dover.guix.info, so I 
> > cannot
> > run guix pull, guix describe, or really anything that is interesting on 
> > there.
> 
> this is a problem I have now seen at least three times, so I have opened
> its own bug:
>https://issues.guix.gnu.org/43720
> 
> Andreas
>

At https://issues.guix.gnu.org/43720 it says
--8<---cut here---start->8---
Your may also send email to 43...@debbugs.gnu.org to comment.
--8<---cut here---end--->8---

(Nit: s/Your/You/ :)

I am wondering what the difference is besides the browser interface,
in regards to how the submission gets logged, stored, and re-distributed.

-- 
Regards,
Bengt Richter

bug#43739: guix archive --export broken on foreign distro

[Ludovic Courtès]

Hi,

Lars-Dominik Braun  skribis:

> as discussed on IRC [1][2] `guix archive --export` is currently broken on
> foreign distributions. It fails with the error message:
>
>   guix archive: error: corrupt input while restoring archive from 
> #
>
> strace reveals `guix authenticate` prints a message to stderr, which the
> guix-daemon does not expect:
>
>   guile: warning: failed to install locale

Specifically, the problem occurs after the change in
64cf660f872fb7aaf0d2b463e45b4c756297f743: on the first call to
‘readAuthenticateReply’, the daemon gets a “g” (from the warning above)
instead of a digit as the protocol expects.

Part of the problem is that ‘Agent’ captures stderr in addition to
stdout, which is useful for ‘guix offload’ but a bad idea for ‘guix
authenticate’.

> See also https://issues.guix.gnu.org/43737

Yup, part of the motivation came from this bug report.

Thanks!

Ludo’.

bug#43747: Spurious Guile warnings when working on a channel

[Ludovic Courtès]

Hello Guix!

When someone’s working on a channel, it’s typical to have that channel
already in your ‘guix’ and to use ‘guix build -L /path/to/checkout PKG’
to test a package from a working copy of the channel.  Here’s what it
looks like:

--8<---cut here---start->8---
$ cat ~/.config/guix/past-channels.scm 
(cons (channel
(name 'guix-past)
(url "https://gitlab.inria.fr/guix-hpc/guix-past;)
(introduction
 (make-channel-introduction
  "0c119db2ea86a389769f4d2b9c6f5c41c027e336"
  (openpgp-fingerprint
   "3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5"
  %default-channels)
$ guix pull -p /tmp/test -C ~/.config/guix/past-channels.scm

[...]

$ /tmp/test/bin/guix build -L ~/src/guix-past/modules autoconf@2.59 -n
;;; note: source file 
/home/ludo/src/guix-past/modules/past/packages/assembly.scm
;;;   newer than compiled 
/gnu/store/6b0ww9dxvfig7wdxqcyjs0hlw331la4z-guix-past/lib/guile/3.0/site-ccache/past/packages/assembly.go
;;; note: source file 
/home/ludo/src/guix-past/modules/past/packages/autotools.scm
;;;   newer than compiled 
/gnu/store/6b0ww9dxvfig7wdxqcyjs0hlw331la4z-guix-past/lib/guile/3.0/site-ccache/past/packages/autotools.go
;;; found fresh local cache at 
/home/ludo/.cache/guile/ccache/3.0-LE-8-4.3/home/ludo/src/guix-past/modules/past/packages/autotools.scm.go
;;; note: source file /home/ludo/src/guix-past/modules/past/packages/backup.scm
;;;   newer than compiled 
/gnu/store/6b0ww9dxvfig7wdxqcyjs0hlw331la4z-guix-past/lib/guile/3.0/site-ccache/past/packages/backup.go
;;; found fresh local cache at 
/home/ludo/.cache/guile/ccache/3.0-LE-8-4.3/home/ludo/src/guix-past/modules/past/packages/backup.scm.go
;;; note: source file 
/home/ludo/src/guix-past/modules/past/packages/guile-xyz.scm
;;;   newer than compiled 
/gnu/store/6b0ww9dxvfig7wdxqcyjs0hlw331la4z-guix-past/lib/guile/3.0/site-ccache/past/packages/guile-xyz.go
;;; found fresh local cache at 
/home/ludo/.cache/guile/ccache/3.0-LE-8-4.3/home/ludo/src/guix-past/modules/past/packages/guile-xyz.scm.go
;;; note: source file /home/ludo/src/guix-past/modules/past/packages/boost.scm
;;;   newer than compiled 
/gnu/store/6b0ww9dxvfig7wdxqcyjs0hlw331la4z-guix-past/lib/guile/3.0/site-ccache/past/packages/boost.go
;;; found fresh local cache at 
/home/ludo/.cache/guile/ccache/3.0-LE-8-4.3/home/ludo/src/guix-past/modules/past/packages/boost.scm.go
;;; note: source file 
/home/ludo/src/guix-past/modules/past/packages/graphviz.scm
;;;   newer than compiled 
/gnu/store/6b0ww9dxvfig7wdxqcyjs0hlw331la4z-guix-past/lib/guile/3.0/site-ccache/past/packages/graphviz.go
;;; note: source file /home/ludo/src/guix-past/modules/past/packages/maths.scm
;;;   newer than compiled 
/gnu/store/6b0ww9dxvfig7wdxqcyjs0hlw331la4z-guix-past/lib/guile/3.0/site-ccache/past/packages/maths.go
;;; note: source file /home/ludo/src/guix-past/modules/past/packages/maths.scm
;;;   newer than compiled 
/home/ludo/.cache/guile/ccache/3.0-LE-8-4.3/home/ludo/src/guix-past/modules/past/packages/maths.scm.go
;;; note: source file /home/ludo/src/guix-past/modules/past/packages/perl.scm
;;;   newer than compiled 
/gnu/store/6b0ww9dxvfig7wdxqcyjs0hlw331la4z-guix-past/lib/guile/3.0/site-ccache/past/packages/perl.go
;;; found fresh local cache at 
/home/ludo/.cache/guile/ccache/3.0-LE-8-4.3/home/ludo/src/guix-past/modules/past/packages/perl.scm.go
;;; note: source file /home/ludo/src/guix-past/modules/past/packages/python.scm
;;;   newer than compiled 
/gnu/store/6b0ww9dxvfig7wdxqcyjs0hlw331la4z-guix-past/lib/guile/3.0/site-ccache/past/packages/python.go
;;; note: source file /home/ludo/src/guix-past/modules/past/packages/python.scm
;;;   newer than compiled 
/home/ludo/.cache/guile/ccache/3.0-LE-8-4.3/home/ludo/src/guix-past/modules/past/packages/python.scm.go
;;; note: source file 
/home/ludo/src/guix-past/modules/past/packages/statistics.scm
;;;   newer than compiled 
/gnu/store/6b0ww9dxvfig7wdxqcyjs0hlw331la4z-guix-past/lib/guile/3.0/site-ccache/past/packages/statistics.go
;;; note: source file /home/ludo/src/guix-past/modules/past/packages/simgrid.scm
;;;   newer than compiled 
/gnu/store/6b0ww9dxvfig7wdxqcyjs0hlw331la4z-guix-past/lib/guile/3.0/site-ccache/past/packages/simgrid.go
;;; found fresh local cache at 
/home/ludo/.cache/guile/ccache/3.0-LE-8-4.3/home/ludo/src/guix-past/modules/past/packages/simgrid.scm.go
;;; note: source file /home/ludo/src/guix-past/modules/past/packages/web.scm
;;;   newer than compiled 
/gnu/store/6b0ww9dxvfig7wdxqcyjs0hlw331la4z-guix-past/lib/guile/3.0/site-ccache/past/packages/web.go
/gnu/store/nah91czddjcb72ghx9kh2z6jwad0kh4d-autoconf-2.59
--8<---cut here---end--->8---

The problem as can be seen above is that all these Guile warnings are
confusing at best and useless: there’s nothing the user can do about
them.

Ludo’.

bug#43277: [PATCH] gnu: emacs-next: Fix load path and version

[Maxim Cournoyer]

Hello!

[...]

>>  gnu/packages/emacs.scm | 37 -
>>  1 file changed, 16 insertions(+), 21 deletions(-)
>>
>> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
>> index 03c28ee7a7..b3d099257d 100644
>> --- a/gnu/packages/emacs.scm
>> +++ b/gnu/packages/emacs.scm
>> @@ -196,11 +196,12 @@
>> (lambda* (#:key outputs #:allow-other-keys)
>>   ;; Directly copy emacs-X.Y to emacs, so that it is not wrapped
>>   ;; twice.  This also fixes a minor issue, where WMs would not 
>> be
>> - ;; able to track emacs back to emacs.desktop.
>> + ;; able to track emacs back to emacs.desktop.  It's done using
>> + ;; this-package so emacs-next can reuse it
>>   (with-directory-excursion (assoc-ref outputs "out")
>> (copy-file (string-append
>> "bin/emacs-"
>> -   ,(version-major+minor (package-version emacs)))
>> +   ,(car (string-split (package-version 
>> this-package) #\-)))
>
> I agree in general it's good to reuse code, however in this particular
> case it's probably better to keep the phases duplicated.  For example,
> in the future one could update the emacs-next package to not require a
> revision number anymore, and it's likely they'd forget to update the
> emacs package since it'll still work.

It's unlikely the emacs-next package would be pegged against a stable
version, but in the event it would, the above code would still work.

[...]

>> `(("autoconf" ,autoconf)
>> - ,@(package-native-inputs emacs))
>> + ,@(package-native-inputs emacs)))
>> +
>> +  (native-search-paths
>> +   (list (search-path-specification
>> +  (variable "EMACSLOADPATH")
>> +  ;; The versioned entry is for the Emacs' builtin libraries.
>> +  (files (list "share/emacs/site-lisp"
>> +   (string-append "share/emacs/" (car (string-split 
>> version #\-)) "/lisp"
>
> nit: This line seems to be a bit long.

Reformatted, and edited the commit message to match our standards.

I made minor, cosmetic changes like below:

modified   gnu/packages/emacs.scm
@@ -196,12 +196,16 @@
(lambda* (#:key outputs #:allow-other-keys)
  ;; Directly copy emacs-X.Y to emacs, so that it is not wrapped
  ;; twice.  This also fixes a minor issue, where WMs would not be
- ;; able to track emacs back to emacs.desktop.  It's done using
- ;; this-package so emacs-next can reuse it
+ ;; able to track emacs back to emacs.desktop.  The version is
+ ;; accessed using using THIS-PACKAGE so it "just works" for
+ ;; inherited Emacs packages of different versions.
  (with-directory-excursion (assoc-ref outputs "out")
(copy-file (string-append
"bin/emacs-"
-   ,(car (string-split (package-version this-package) 
#\-)))
+   ,(let ((this-version (package-version 
this-package)))
+  (or (false-if-exception
+   (version-major+minor+point this-version))
+  (version-major+minor this-version
   "bin/emacs")
#t)))
  (add-before 'reset-gzip-timestamps 'make-compressed-files-writable
@@ -304,7 +308,9 @@ languages.")
   (variable "EMACSLOADPATH")
   ;; The versioned entry is for the Emacs' builtin libraries.
   (files (list "share/emacs/site-lisp"
-   (string-append "share/emacs/" (car (string-split 
version #\-)) "/lisp"
+   (string-append "share/emacs/"
+  (version-major+minor+point version)
+  "/lisp"
  (search-path-specification
   (variable "INFOPATH")
   (files '("share/info"

Verified it produced a correct EMACSLOADPATH and ran using:

--8<---cut here---start->8---
$ guix environment --pure --ad-hoc emacs-next
[...]
[env]$ echo $EMACSLOADPATH
/gnu/store/6s7p3yi969pm2xmkdd45dljbnwy5107g-profile/share/emacs/site-lisp:/gnu/store/6s7p3yi969pm2xmkdd45dljbnwy5107g-profile/share/emacs/28.0.50/

[env]$ emacs --version
GNU Emacs 28.0.50
--8<---cut here---end--->8---

And pushed to master as commit 0f88fea0eaa.

Thanks everyone!

Closing,

Maxim

bug#43746: What to do about packages that don't support --without-tests / #:tests? #f setting

[pelzflorian (Florian Pelz)]

The new package transformation option --without-tests works by setting
#:tests? #f in the specified packages.  But some packages replace
their 'check phase and no longer honor #tests?.  glib for example.

Attached is an attempt to document this current behavior.  Shall I
push it?  Alternatively, it should be documented to write a check
phase that honors #:tests?.  Or the package transformation should be
changed to remove any check phase it finds.

Regards,
Florian>From b55e6ee01fe674b282e7ec75d0e4c8a839262261 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Thu, 1 Oct 2020 15:35:52 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] doc: Explain why '--without-tests' may fail with modified
 'check' phase.

* doc/guix.texi (Package Transformation Options): Explain.
---
 doc/guix.texi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index e8458ad8d8..6a2bd629cb 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -9350,6 +9350,12 @@ The command above installs @code{python-notebook} on top 
of
 rebuilds everything that depends on @code{python}, including
 @code{python-notebook} itself.
 
+Internally, @code{--without-tests} relies on changing the
+@code{#:tests?} option of a package's @code{check} phase (@pxref{Build
+Systems}).  Note that some packages use a customized @code{check} phase
+that does not respect a @code{#:tests? #f} setting.  Therefore there are
+some packages for which @code{--without-tests} cannot disable tests.
+
 @end table
 
 @node Additional Build Options
-- 
2.28.0

bug#43579: g++ does not provide std::fegetround

[Ludovic Courtès]

Hallo!

Andreas Enge  skribis:

> The following test file round.cpp does not compile with our g++-10.2.0:
> #include 
> int main () {
>return std::fegetround ();
> }

Could you provide detailed steps to reproduce it?

Thanks,
Ludo’.

bug#43744: guix-install.sh should do more first-time setup

[Ludovic Courtès]

Hello!

One of the things we can do to provide a better first-time experience on
a foreign distro is to automatically do some of the things that make
Guix readily usable and convenient, even for someone who skips the
“Application Setup” section of the manual.  Things that come to mind:

  1. Installing Bash and Zsh completion files globally (actually making
 them a symlink to
 /var/guix/profiles/per-user/root/current-guix/etc/…).
 There seems to be +/- a cross-distro conventional directory to
 collect those, for example /etc/bash_completion.d, no?  The script
 could create that symlink, perhaps asking the user to confirm.

  2. Adding the following lines to /etc/profile (taken from Guix System):

--8<---cut here---start->8---
# Arrange so that ~/.config/guix/current comes first.
for profile in "$HOME/.guix-profile" "$HOME/.config/guix/current"
do
  if [ -f "$profile/etc/profile" ]
  then
# Load the user profile's settings.
GUIX_PROFILE="$profile" ; \
. "$profile/etc/profile"
  else
# At least define this one so that basic things just work
# when the user installs their first package.
export PATH="$profile/bin:$PATH"
  fi
done
--8<---cut here---end--->8---

 The user should be explicitly asked whether they want this change
 to be made.

  3. It could check “ps aux | grep nscd” and install nscd using the host
 distro package manager if needed, or at least suggest doing it.

Any takers?  :-)

Thanks,
Ludo’.

bug#43491: Fakechroot execution engine can fail to find libraries

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> The patch below fixes the issue for this particular example by simply
> passing the whole RUNPATH of the wrapped executable as ‘--library-path’,
> as was the case in v1 of the patch set¹.  (This assumes that the RUNPATH
> of pack-audit.so is a subset of that of the program, which is usually
> the case.)

I pushed this as a workaround as commit
58abd5873985e0cd9a2926867bf697c5e7bc01f9.

The ld.so issue is still open but there seems to be consensus that it’s
a bug: .

Closing!

Ludo’.

bug#43668: Daemon tries to build GNU/Hurd derivations on GNU/Linux

[Ludovic Courtès]

Hi,

Jan Nieuwenhuizen  skribis:

>> Yeah, I think we’ll have to do this hack (we’re not going to parse ELF
>> files and all to determine whether to call ‘execve’.)
>
> Ah, we're C++; I was thinking Guile and "we surely have" an ELF library.
> That's allright then.  Let's have this workaround.

Yeah.  Even with a library, it doesn’t sound right to parse files
beforehand.  I think it’s up to the kernel to make the relevant check,
but perhaps there are good reasons why this isn’t happening here.

Anyway, pushed as 9556ac498fd648147ad7d3b52ec86202d0a8e171!

>> (Besides, it would be interesting to understand how the libc/Hurd
>> startup code ends up segfaulting on GNU/Linux.)
>
> Hmm...are you saying something like "it could run until it wants to RCP
> Mach or Hurd?"  Might it "just load" shared libraries...

Yeah I would expect it to run code up to the first Mach syscall but here
it segfaults so maybe it crashes earlier.

Ludo’.

bug#43738: Patch file names too long

[Ludovic Courtès]

There are several patch file names that are too long for ‘tar’, as
reported during ‘make dist’:

--8<---cut here---start->8---
tar: 
guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/ocaml-bisect-fix-camlp4-in-another-directory.patch
 dosiernomo tro longas (maks 99); ne ŝutita
tar: 
guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/audiofile-signature-of-multiplyCheckOverflow.patch
 dosiernomo tro longas (maks 99); ne ŝutita
tar: 
guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/python2-pygobject-2-gi-info-type-error-domain.patch
 dosiernomo tro longas (maks 99); ne ŝutita
tar: 
guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/audiofile-division-by-zero-BlockCodec-runPull.patch
 dosiernomo tro longas (maks 99); ne ŝutita
tar: 
guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/python-robotframework-honor-source-date-epoch.patch
 dosiernomo tro longas (maks 99); ne ŝutita
--8<---cut here---end--->8---

‘guix lint’ reports it as well, but apparently this is easily
overlooked.

Ludo’.

bug#43529: Guix Interactive Installer Broken

[Yasuaki Kudo]

let me try over the weekend 

> On Sep 30, 2020, at 02:17, zimoun  wrote:
> 
> Dear,
> 
> Thank you for the feedback.
> 
>> On Sun, 20 Sep 2020 at 16:51, Yasuaki Kudo  wrote:
>> 
>> Is there a bug tracker ID already assigned for this?
> 
> Do you hit the bug using the last image [1]?
> 
> [1] 
> 
> 
> 
> All the best,
> simon

bug#43736: The local-file()'s error message is misleading.

[Vitaliy Shatrov]

Hello there.
I ran in bash shell:



pwd
--> /home/vits

conf=~/guix/configuration/configuration.scm

ls $conf   # file exists
--> ~/guix/configuration/configuration.scm

guix system build $conf
--> guix system: error: failed to load
'/home/vits/guix/configuration/configuration.scm': No such file or directory



The commands above will result in a successfull build if i
`cd guix/configuration` before doing `guix system build`
(both with rel. and abs. names).

Attached is WORKING config.scm.  Error was caused by local-file()
used with _relative_ paths.  Those were commented out, and this
config.scm works from any directory.

#guix:
> ... error message is very misleading.

Better of course if the offending file will be print out:
"failed to load (...) /home/vits/auto-login:  no such file or directory"

---
Thanks for attention, Vitaliy.


config.scm
Description: Binary data