bug#31216: commit 217b8c2e0 produces 'Can't locate Date/Parse.pm in @INC Error' perl error

[George myglc2 Clemmer]

Commit ...

217b8c2e0 * gnu: perl: Replace with 5.26.2 [fixes
CVE-2018-{6797,6798,6913}].

... caused the attached perl script that worked like this ...

g1@g1 ~/.mail-mirror$ guix environment --ad-hoc perl perl-timedate make wget
g1@g1 ~/.mail-mirror [env]$ perl mb2md-3.20.pl
Usage:
   mb2md -h
   mb2md [-c] -m [-d destdir]
   mb2md [-c] -s sourcefile [-d destdir]
   mb2md [-c] -s sourcedir [-l wu-mailboxlist] [-R|-f somefolder] [-d 
destdir] [-r strip_extension]
g1@g1 ~/.mail-mirror [env]$


... to stop working ...

g1@g1 ~/.mail-mirror$  guix environment --ad-hoc perl perl-timedate make wget
g1@g1 ~/.mail-mirror [env]$  perl mb2md-3.20.pl
Can't locate Date/Parse.pm in @INC (you may need to install the Date::Parse 
module) (@INC contains: 
/gnu/store/wpwb4ig3qhv3m7axjlid2c0f1jqzp09p-profile/lib/perl5/site_perl/5.26.2/x86_64-linux-thread-multi
 /gnu/store/wpwb4ig3qhv3m7axjlid2c0f1jqzp09p-profile/lib/perl5/site_perl/5.26.2 
/gnu/store/wpwb4ig3qhv3m7axjlid2c0f1jqzp09p-profile/lib/perl5/site_perl 
/gnu/store/ynk3rg3i791i6k7rz2imbyj9wyfjrnrc-perl-5.26.2/lib/perl5/site_perl/5.26.2/x86_64-linux-thread-multi
 
/gnu/store/ynk3rg3i791i6k7rz2imbyj9wyfjrnrc-perl-5.26.2/lib/perl5/site_perl/5.26.2
 
/gnu/store/ynk3rg3i791i6k7rz2imbyj9wyfjrnrc-perl-5.26.2/lib/perl5/5.26.2/x86_64-linux-thread-multi
 /gnu/store/ynk3rg3i791i6k7rz2imbyj9wyfjrnrc-perl-5.26.2/lib/perl5/5.26.2) at 
mb2md-3.20.pl line 385.
BEGIN failed--compilation aborted at mb2md-3.20.pl line 385.
g1@g1 ~/.mail-mirror [env]$

TIA - George



mb2md-3.20.pl
Description: Binary data

bug#31069: emacs-smartparens: sp-forward-barf-sexp broken

[Christopher Lemmer Webber]

Thorsten Wilms writes:

> On 07.04.2018 17:19, Alex Kost wrote:
>
>> Sorry, I don't know what could cause your problem.  My only idea is
>> maybe you have some mixed (incompatible) packages both from Guix and
>> from (M)ELPA (for example, "dash.el" from Melpa and "smartparens" from
>> Guix).  Look at "M-x list-load-path-shadows".
>
> No worries, thanks for your input!
>
> There's nothing here that wasn't installed via guix.
> list-load-path-shadows says:
>
> /home/thorwil/.guix-profile/share/emacs/site-lisp/site-start hides
> /gnu/store/6cflji7h6y0v15dvnccv7paaa7894gdc-emacs-25.3/share/emacs/site-lisp/site-start
> /home/thorwil/.guix-profile/share/emacs/site-lisp/guix-emacs hides
> /gnu/store/6cflji7h6y0v15dvnccv7paaa7894gdc-emacs-25.3/share/emacs/site-lisp/guix-emacs
>
>
> So far all this happened on Ubuntu with just Emacs and packages for it
> installed via guix. Now I tried what happens on Guix SD, with
> emacs-smartparens as only Emacs package, run in the shell, no
> init.el. After just M-x smartparens-mode, again: slurp works, barf
> doesn't.
>
> I would conclude that this is a direct smartparens bug, if it wasn't
> for your report of having it working (which I do not doubt).

I have the same problem BTW.  It started happening after a recent
upgrade.

bug#31113: mcron ERROR: In procedure mktime:

[Ludovic Courtès]

Hello,

Rutger Helling  skribis:

> I had this problem too. 
>
> Reverting commit cfbf6de18cc70d2e385feb5f61f9363f18e78ddf (gnu: mcron:
> Update to 1.1 and deprecate "mcron2".) fixed it for me.

This was a bug in mcron 1.1.

Fixed in commit 67a51b675538065a4ec3eb06428d8a4021fdbb87, which updates
to 1.1.1.

Thanks!

Ludo’.

bug#28261: libfreeimage has undefined references

[Ludovic Courtès]

Hello Efraim,

It seems that commit a5d4c96b8d90b8bb87e07bd6a7be78991db91bc9 left
libfreeimage with some undefined references.  For instance, the
‘configure’ script of ‘guile-sly’ fails like this:

--8<---cut here---start->8---
configure:3888: checking for FreeImage_GetVersion in -lfreeimage
configure:3913: gcc -o conftest -g -O2   conftest.c -lfreeimage   >&5
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `PixelFormatLookup'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat16bppRGB555'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat16bppGray'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat24bppRGB'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `PKFormatConverter_Release'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat8bppGray'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `PKImageDecode_Create_WMP'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `PKAllocAligned'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `PKImageEncode_Create_WMP'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat24bppBGR'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormatDontCare'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat96bppRGBFloat'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `PKImageEncode_SetGPSInfoMetadata_WMP'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `PKFormatConverter_EnumConversions'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat48bppRGB'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `PKFreeAligned'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormatBlackWhite'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat32bppBGRA'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat32bppRGB'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat64bppRGBA'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `PKCodecFactory_CreateFormatConverter'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `PKImageEncode_SetEXIFMetadata_WMP'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `PKImageEncode_SetXMPMetadata_WMP'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat128bppRGBAFloat'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat32bppGrayFloat'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `PKImageEncode_SetIPTCNAAMetadata_WMP'
/gnu/store/lsbwqzbl17xvbp4clv2mlxmly2xkz219-freeimage-3.17.0/lib/libfreeimage.so:
 undefined reference to `GUID_PKPixelFormat16bppRGB565'
collect2: error: ld returned 1 exit status
configure:3913: $? = 1
--8<---cut here---end--->8---

Any ideas?

Thanks,
Ludo’.

bug#31162: "guix pull" broke itself

[Danny Milosavljevic]

Hi Ludo,

> You should grep in ~/.config/guix/latest as well.

~/.config/guix/latest$ grep -r util-linux-2.31 .
./gnu/packages/linux.scm:(define-public util-linux-2.31.1
./gnu/system.scm: util-linux-2.31.1
Binary file ./gnu/system.go matches

> I can’t seem to reproduce the issue though.  Is it just running ‘guix
> pull’ that breaks, or do ‘guix package’ or ‘guix system’ fail similarly?

'guix package' and 'guix system' fail as well, with the same message.


pgpfHfIeON8UX.pgp
Description: OpenPGP digital signature

bug#31187: core-updates: url-fetch/tarbomb, url-fetch/zipbomb fail with "unbound variable: invoke"

[Glenn Morris]

Mark H Weaver wrote:

> (1) This bug is not listed on , although
>  shows it as an open bug for Guix.

There was a problem with the pagination. It's (now) on page 2.

> (2) The original bug report was never delivered to me, although I'm
> subscribed to .  If Eric hadn't CC'd me on his
> original submission, I might not have seen it. 

I would guess that you are subscribed to bug-guix with the "filter out
duplicates" Mailman option, so it is precisely because you were cc'd
that you did not get the mailing list copy (with the bug number).

> I was unable to find out the bug number until I asked Eric directly,
> so unfortunately the commit does not reference the bug number.

(You could have searched for the bug by subject?)

If Eric had used X-Debbugs-CC instead of Cc in the initial report, the
mail you got would have included the bug number in the subject.
I believe this is well documented (eg on the "how to report a bug"
section on https://debbugs.gnu.org/).

> I've reported these problems to the FSF sysadmins, and I'd like to give
> them an opportunity to diagnose the problem before we change the status
> of this bug.

The FSF sysadmins don't maintain debbugs.gnu.org, so the help-debbugs
list would have been better. I (debbugs.gnu.org maintainer) happened to
see your mail although I don't normally read bug-guix.

bug#31162: "guix pull" broke itself

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> $ guix pull
> Updating from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
> Building from Git commit fc12113704255616522cb56fc37b4a18fccd84eb...
> Backtrace:
> In ice-9/boot-9.scm:
>2862:4 19 (define-module* _ #:filename _ #:pure _ #:version _ # _ …)
>   2071:24 18 (call-with-deferred-observers #)
>   2875:24 17 (_)
>222:17 16 (map1 (((gnu)) ((guix)) ((guix ui)) ((guix config)) # …))
>   2788:17 15 (resolve-interface (gnu) #:select _ #:hide _ #:prefix _ …)
>   2714:10 14 (_ (gnu) _ _ #:ensure _)
>   2982:16 13 (try-module-autoload _ _)
>2312:4 12 (save-module-excursion #)
>   3002:22 11 (_)
> In unknown file:
>   10 (primitive-load-path "gnu" #)
> In gnu.scm:
>  58:4  9 (_)
> In ice-9/boot-9.scm:
>260:13  8 (for-each # (# …))
> In gnu.scm:
> 60:33  7 (_ (gnu system))
> In ice-9/boot-9.scm:
>   2788:17  6 (resolve-interface (gnu system) #:select _ #:hide _ # _ …)
>   2714:10  5 (_ (gnu system) _ _ #:ensure _)
>   2982:16  4 (try-module-autoload _ _)
>2312:4  3 (save-module-excursion #)
>   3002:22  2 (_)
> In unknown file:
>1 (primitive-load-path "gnu/system" #)
> In gnu/system.scm:
> 508:0  0 (_)
>
> gnu/system.scm:508:0: util-linux-2.31.1: unbound variable
>
> $ ls -l $(which guix)
> /run/current-system/profile/bin/guix -> 
> /gnu/store/xzz0xn80jp48fzy5xz4k8nmwwz1badgc-guix-0.14.0-9.bdf0c64/bin/guix
>
> $ grep -r util-linux-2.31 
> /gnu/store/xzz0xn80jp48fzy5xz4k8nmwwz1badgc-guix-0.14.0-9.bdf0c64/share/guile/site/2.2/gnu/

You should grep in ~/.config/guix/latest as well.

I can’t seem to reproduce the issue though.  Is it just running ‘guix
pull’ that breaks, or do ‘guix package’ or ‘guix system’ fail similarly?

Ludo’.

bug#31142: guix package --upgrade reverses the order of packages

[Ludovic Courtès]

Hello,

Chris Marusich  skribis:

> It seems that running "guix package --upgrade ." reverses the order of
> packages installed in a profile.  Apparently as a result, repeatedly
> running the command on a profile will create multiple generations, even
> though the packages are not actually being upgraded.

Commit eca16a3d1d9e6b2c064e0105c1015258bf2755f2 was supposed to fix it…
but it lacked a test case…  I plaid guilty.  :-)

Could you take a closer look at that commit?

Ludo’.

bug#31210: Perl graft breakage

[Leo Famulari]

On Wed, Apr 18, 2018 at 03:14:45PM -0400, Mark H Weaver wrote:
> I suggest that we add a phase to the replacement 'perl' to install a
> symlink from $out/lib/perl5/5.26.1 pointing to "5.26.2".
> 
> Would you like to try this, Leo, and push it if it solves the problem
> for you?

Thanks for your advice. The attached patch fixes the issue for me.

I would have pushed it but there is one thing I don't understand. Before
I set (replacement #f), the build would fail because the new phase was
run twice, and symlinking fails because it is not "forced" (as in `ln
-sf`). Is this expected behaviour?
From b49afa6cf9e18d57e67c0580a09e0ee9168218e7 Mon Sep 17 00:00:00 2001
From: Leo Famulari 
Date: Wed, 18 Apr 2018 16:41:39 -0400
Subject: [PATCH] gnu: Perl: Fix a grafting failure due to a path that includes
 the package version.

Fixes .

* gnu/packages/perl.scm (perl-5.26.2)[arguments]: Add a
'workaround-grafting-version-bug' phase.
---
 gnu/packages/perl.scm | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 34eef565b..24e055225 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -43,6 +43,7 @@
   #:use-module (guix download)
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system perl)
+  #:use-module (guix utils) ;substitute-keyword-arguments for perl-5.26.2
   #:use-module (gnu packages base)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages perl-check)
@@ -161,13 +162,27 @@
 (define-public perl-5.26.2
   (package/inherit perl
 (version "5.26.2")
+(replacement #f)
 (source (origin
   (inherit (package-source perl))
   (uri (string-append "mirror://cpan/src/5.0/perl-"
   version ".tar.gz"))
   (sha256
(base32
-"03gpnxx1g6hvlh0v4aqx00580h787sfywp1vlvw64q2xcbm9qbsp"))
+"03gpnxx1g6hvlh0v4aqx00580h787sfywp1vlvw64q2xcbm9qbsp"
+(arguments
+ (substitute-keyword-arguments (package-arguments perl)
+   ((#:phases phases)
+`(modify-phases ,phases
+   ;; The path to libperl.so includes the Perl version number, and this
+   ;; is not handled by grafting. See .
+   (add-after 'install 'workaround-grafting-version-bug
+ (lambda* (#:key outputs #:allow-other-keys)
+   (let* ((out (assoc-ref outputs "out"))
+  (new (string-append out "/lib/perl5/5.26.2"))
+  (old (string-append out "/lib/perl5/5.26.1")))
+ (symlink new old)
+ #t)
 
 (define-public perl-algorithm-c3
   (package
-- 
2.17.0



signature.asc
Description: PGP signature

bug#31159: Reverse order for old grub.cfg entries

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>> I agree with you.  As long as the entry labels clearly show which one is
>> the most recent, that sounds good.
>>
>> However!  On headless machines, we’d rather make sure users know about
>> this change.  On our Libreboot “bayfront” server, GRUB for some reason
>> fails to display anything, and on several occasions we’ve had to blindly
>> select an older generation.  Hopefully this is an unusual situation ;-),
>> but it could happen on ARM boards as well.
>
> Do you have an idea of how to make sure that users know about it?

Not really.  I think we can at least send a heads-up to guix-devel and
help-guix.

Ludo’.

bug#31187: core-updates: url-fetch/tarbomb, url-fetch/zipbomb fail with "unbound variable: invoke"

[Mark H Weaver]

Hi Eric,

Eric Bavier  writes:

> In commit 20927c9331b493eaf94211ad9f8a5055e11b4588
> url-fetch/tarbomb and url-fetch/zipbomb in guix/download.scm were
> switched to use 'invoke' instead of 'system*'.  On core-updates this
> leads for me to an error when attempting to build the source for
> packages that use these fetch methods.

[...]

> If I revert that commit it succeeds.  I suppose the (guix build utils)
> module needs to be imported into the builder.

Indeed, you are right.  Commit 6c293a809bba57d4363517fa0bd8ebc34247c577
on core-updates should fix this problem.  Thanks for the report.

However, let's leave this bug report open for now.

The reason is that debbugs.gnu.org mishandled this report in two ways:

(1) This bug is not listed on , although
 shows it as an open bug for Guix.

(2) The original bug report was never delivered to me, although I'm
subscribed to .  If Eric hadn't CC'd me on his
original submission, I might not have seen it.  I was unable to find
out the bug number until I asked Eric directly, so unfortunately the
commit does not reference the bug number.

I've reported these problems to the FSF sysadmins, and I'd like to give
them an opportunity to diagnose the problem before we change the status
of this bug.

  Thanks,
Mark

bug#31159: Reverse order for old grub.cfg entries

[Mark H Weaver]

Hi Ludovic,

l...@gnu.org (Ludovic Courtès) writes:
> I agree with you.  As long as the entry labels clearly show which one is
> the most recent, that sounds good.
>
> However!  On headless machines, we’d rather make sure users know about
> this change.  On our Libreboot “bayfront” server, GRUB for some reason
> fails to display anything, and on several occasions we’ve had to blindly
> select an older generation.  Hopefully this is an unusual situation ;-),
> but it could happen on ARM boards as well.

Do you have an idea of how to make sure that users know about it?

  Mark

bug#31210: Perl graft breakage

[Mark H Weaver]

Hi Leo,

Leo Famulari  writes:

> On Sun, Apr 15, 2018 at 05:34:05PM +0200, Marius Bakke wrote:
>> * gnu/packages/perl.scm (perl-5.26.2): New public variable.
>> (perl)[replacement]: New field.
>
> I noticed on my Debian system that this broke rxvt-unicode, and it
> probably affects other packages as well.
>
> The issue is that the full path of libperl.so includes the Perl version
> number, for example:
>
> /gnu/store/...-perl-5.26.1/lib/perl5/5.26.1/x86_64-linux-thread-multi/CORE/libperl.so
>
> The RUNPATH of urxvt with the Perl graft includes this bogus path:
>
> /gnu/store/ynk3rg3i791i6k7rz2imbyj9wyfjrnrc-perl-5.26.2/lib/perl5/5.26.1/x86_64-linux-thread-multi/CORE

I suggest that we add a phase to the replacement 'perl' to install a
symlink from $out/lib/perl5/5.26.1 pointing to "5.26.2".

Would you like to try this, Leo, and push it if it solves the problem
for you?

   Mark

bug#31210: Perl graft breakage

[Leo Famulari]

On Sun, Apr 15, 2018 at 05:34:05PM +0200, Marius Bakke wrote:
> * gnu/packages/perl.scm (perl-5.26.2): New public variable.
> (perl)[replacement]: New field.

I noticed on my Debian system that this broke rxvt-unicode, and it
probably affects other packages as well.

The issue is that the full path of libperl.so includes the Perl version
number, for example:

/gnu/store/...-perl-5.26.1/lib/perl5/5.26.1/x86_64-linux-thread-multi/CORE/libperl.so

The RUNPATH of urxvt with the Perl graft includes this bogus path:

/gnu/store/ynk3rg3i791i6k7rz2imbyj9wyfjrnrc-perl-5.26.2/lib/perl5/5.26.1/x86_64-linux-thread-multi/CORE

Grafting fails to replace the latter instance of the version number,
and so lookups fail like this:

--
[...]
openat(AT_FDCWD, 
"/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libperl.so",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/libperl.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/95b2fv709zvxdrb38l2w8jd73vz5v5ff-fontconfig-2.12.6/lib/libperl.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/4pj266bvxiris0vbvm1j568n1smdj7m8-freetype-2.8.1/lib/libperl.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/6n2pn58p6l7v9icg0m3i8kp4wbn8nzl2-libxft-2.3.2/lib/libperl.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/7lm90jgm2y00382yqriq4yw1nvb3p7b6-libxrender-0.9.10/lib/libperl.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/6x1p96h51dlgpdsmrx3821ixbawbm19l-libx11-1.6.5/lib/libperl.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../tls/x86_64/x86_64/libperl.so",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../tls/x86_64/x86_64",
 0x7ffd43384b10) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../tls/x86_64/libperl.so",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../tls/x86_64",
 0x7ffd43384b10) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../tls/x86_64/libperl.so",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../tls/x86_64",
 0x7ffd43384b10) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../tls/libperl.so",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../tls",
 0x7ffd43384b10) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../x86_64/x86_64/libperl.so",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../x86_64/x86_64",
 0x7ffd43384b10) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../x86_64/libperl.so",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../x86_64",
 0x7ffd43384b10) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../x86_64/libperl.so",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../x86_64",
 0x7ffd43384b10) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../../libperl.so",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/gnu/store/2ifmksc425qcysl5rkxkbv6yrgc1w9cs-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../..",
 {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
openat(AT_FDCWD, 

bug#31159: Reverse order for old grub.cfg entries

[Ludovic Courtès]

Hello,

Mark H Weaver  skribis:

> Mathieu Othacehe  writes:
>
>> This seems like a good idea ! If we decide to make it unconditional the
>> patch attached does the job. We can also make it configurable in
>> bootloader-configuration for instance.
>>
>> WDYT ?
>
> Thank you, Mathieu!  I doubt that there's a need to make this
> configurable, but I'd like to hear an opinion from Ludovic, since I
> guess he was the one who implemented the current ordering.
>
> What do you think, Ludovic?

I agree with you.  As long as the entry labels clearly show which one is
the most recent, that sounds good.

However!  On headless machines, we’d rather make sure users know about
this change.  On our Libreboot “bayfront” server, GRUB for some reason
fails to display anything, and on several occasions we’ve had to blindly
select an older generation.  Hopefully this is an unusual situation ;-),
but it could happen on ARM boards as well.

Ludo’.