bug#36870: was: date bug -- really locale bug or ??

[Mark H Weaver]

Hi Bengt,

I'm sorry that I didn't have time to fully read your messages, but if I
understand correctly from my quick skimming, the 'date' command from
Guix is failing to access the zoneinfo.  I think I see your problem.

Bengt Richter  writes:
> $ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n:g'
> openat(AT_FDCWD,
>  
> "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles",
>  O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

The file name above suggests that your TZDIR variable is not set
correctly to allow Guix-built binaries to find the zoneinfo files.

On Guix systems, /etc/environment includes an entry that sets TZDIR to
the equivalent of "$(guix build tzdata)/share/zoneinfo".

When using Guix on top of another distro, an alternative choice might be
to set TZDIR to "/usr/share/zoneinfo".  I'm not sure which setting is
preferable on non-Guix systems.

Can you try setting TZDIR and see if that solves the problem for you?

 Regards,
   Mark

bug#36876: guix system delete-generations removes custom boot menu entries

[Jesse Gibbons]

On Mon, 2019-08-05 at 12:05 -0400, Jakob L. Kreuze wrote:
> ...
> 
> I don't think this should be _too_ hard to fix. To me, parsing the
> installed Grub configuration to get existing menu entries seems like
> a
> logical step forward.
> 
> Thoughts from anyone else?
> 
> Regards,
> Jakob

Alternatively, we could save in the store a derivation for the the grub
config generated from the bootloader of the configuration. When the
user calls "guix system delete-generations", the derivation can be run,
and the remaining system generations (if any) can be appended in a menu
like when the user calls "guix system reconfigure". (Although it does
not work for me right now, I'm assuming "guix system delete-generations 
2m" as described in the manual will be implemented in the future.)

The immediate downsides I see to my solution:

- It would take space in the store per generation, which can add up if
the user does not often call "guix system delete-generations" and calls
"guix system reconfigure" on a healthy basis. The user could just be
reminded to call "guix system delete-generations" occasionally, and any
 official service that automatically updates the system via "guix
system reconfigure" can (and considering how large a generation with a
lot of updated system packages can get, probably should) also be
configured to call "guix system delete-generations".

- If someone hand-edits the grub config the changes would be lost. This
is the case as it is right now, and grub options can be edited in the
configuration, so I'm not too concerned about this.

-It would be much simpler to identify menu entries generated by guix
that are no longer in the store and remove them, and remove all empty
submenus. Parsing would make hand-editing grub.cfg more dangerous than
a solution that simply scraps the hand-made changes and rebuilds as I
propose, because the user doing the hand-editing would not necessarily
be aware what patterns the parser checks. It would also be inconsitent:
edits to grub.cfg being scrapped when "guix system reconfigure" is
called, but not when 'guix system delete-generations" is called looks
to me like a good way to introduce a bug to the more adventurous
"Murphy's Law"-type users down the road.


These are just my thoughts. I would love to hear other downsides to my
solution.

-- 
-Jesse

bug#36878: guix system reconfigure broken

[ison]

On Mon, Aug 05, 2019 at 10:59:57AM -0400, Jakob L. Kreuze wrote:
> ison -- I'm very sorry that you've had this experience. Would you be
> willing to share the 'bootloader' field of your operating system
> configuration so I can look into this?

Thanks for taking an interest. Here is the new bug report:
https://issues.guix.gnu.org/issue/36942

Please let me know if there's any other information or testing I
can do to help figure it out.

bug#36870: was: date bug -- really locale bug or ??

[Bengt Richter]

Hi all, following up on myself, sorry I lost my copy of
my original, so this does not contain any quoting, but
this can stand on its own as a new problem statement.

Problem should go away if I can get locales working,
but despite trying what purportedly has worked for others,
no luck. I hope it will be obvious to someone from the below ;-)

$ # first some context:
$ uname -rv
5.1.15-arch1-1-ARCH #1 SMP PREEMPT Tue Jun 25 04:49:39 UTC 2019
$ guix -V
guile: warning: failed to install locale
guix (GNU Guix) a17fe3f01ac160a576135b03d23bc098ebf6fb31
Copyright (C) 2019 the Guix authors
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ ### that warning -- "guile: warning: failed to install locale" might be a 
clue in that
$ ### it does _NOT_ happen in the direct bash console environment, but does in 
emacs's M-x shell ...
$ cat ~/bin/pidparents  ## something to show where I am, that I find useful
#!/usr/bin/bash
# ~/bin/parentage

pid=${1:-$$}#this process if no pid specified as $1

while [ $(($pid)) -gt 0 ]; do
  ps h -p $pid -o comm,tt,pid,stat,args
  pid=$(ps -q $pid -o ppid=)
done
$ pidparents ## from here in emacs's shell
pidparents  pts/0 9286 S+   /usr/bin/bash /home/bokr/bin/pidparents
bashpts/0 6884 Ss   /bin/bash --noediting -i
.emacs-26.2-rea tty4  6393 Sl+  
/gnu/store/9nrncjaxygfrr9q749pymcw3l9vywh0k-emacs-26.2/bin/emacs-26.2 
/home/bokr/.mutt/temp/mutt-PhantoNv4ArchGx-1000-6327-
mutttty4  6327 Smutt
bashtty4 24159 Sbash
bashtty4  3608 Ss   -bash
login   ? 3601 Ss   login -- bokr
systemd ?1 Ss   /sbin/init 
\EFI\PhantoNv4ArchGx\vmlinuz-linux
$ ### does something depend on ttyN vs pts/N ?? don't think so, but maybe some 
env gets lost in pts start?
$
$ 
$ ### here I call the guix date vs the archlinux date at /usr/bin/date -- note 
the difference
$ which -a date
/home/bokr/.guix-profile/bin/date
/usr/bin/date
$ 

$ strace -y date|& egrep 'America|^write'|sed -e 's:,:,\n:g'
openat(AT_FDCWD,
 
"/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/zoneinfo/America/Los_Angeles",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(1,
 "Mon Aug  5 18:22:52 America 2019"...,
 33Mon Aug  5 18:22:52 America 2019
$ 
$ strace -y /usr/bin/date|& egrep 'America|^write'|sed -e 's:,:,\n:g'
openat(AT_FDCWD,
 "/usr/share/zoneinfo/America/Los_Angeles",
 O_RDONLY|O_CLOEXEC) = 4
fstat(4,
 {st_mode=S_IFREG|0644,
 st_size=2836,
 ...}) = 0
fstat(4,
 {st_mode=S_IFREG|0644,
 st_size=2836,
 ...}) = 0
read(4,
 "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"...,
 4096) = 2836
lseek(4,
 -1802,
 SEEK_CUR) = 1034
read(4,
 "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"...,
 4096) = 1802
close(4) = 0
write(1,
 "Mon 05 Aug 2019 11:23:06 AM PDT\n",
 32Mon 05 Aug 2019 11:23:06 AM PDT
$


I put

export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale/"
export LC_ALL=en_US.utf8

in both ~/.bash_profile and ~/.bashrc
and still no joy
 
I'm wondering whether I have to reboot, not just log out and back in,
to get locales into effect. Have been trying and searching, but something
is eluding me ;-/ [later, after rebooting -- nope, reboot didn't do it :( ]

Generation 37   Aug 02 2019 01:42:29
 + tzdata   2019b   out 
/gnu/store/kmsqjsrwryfnz6p9pb4yysly71221blv-tzdata-2019b

Generation 38   Aug 04 2019 15:39:34
 + glibc-locales2.28out 
/gnu/store/bb9alx1ap57pz0vmx7p1r8qk0lxxfg3x-glibc-locales-2.28

Generation 39   Aug 05 2019 08:08:19
 + localed  241 out 
/gnu/store/98mpw3n6j34dsnq63hb14bpfv9bxq9f4-localed-241

(Hm, guess I ought to clean out some generations)

Any ideas appreciated. Am I the only one seeing this?
I first noticed because who -b gave me UTC time instead of local time.

Thanks.
Regards,
Bengt Richter

bug#36942: Reconfigure broke GRUB

[ison]

Continuing this issue from https://issues.guix.gnu.org/issue/36878

guix reconfigure recently broke GRUB for me. When rebooting I get
dropped to a "grub rescue>" shell with an error about
"grub_file_filters" being an unknown symbol.
If I try doing the usual commands to tell GRUB how to boot I just
see the above error repeated, or "unknown command" when I run
things such as insmod or "configfile".

So to fix the problem I can boot to a Guix install disk and do
"guix init" which rebuilds the system using older package
definitions from the disk.
That allows me to get a working system, but if I do another
"guix pull" and reconfigure using the same config file it breaks
GRUB again when I reboot. "guix describe" shows that my latest
attempt was with commit 35600cd.

Here is the bootloader and filesystem sections of my config:
  (bootloader (bootloader-configuration
(bootloader grub-efi-bootloader)
(target "/boot/efi")))
  (file-systems (cons* (file-system
 (device "/dev/sda2")
 (mount-point "/boot/efi")
 (type "vfat"))
   (file-system
 (device (file-system-label "guixsd-root"))
 (mount-point "/")
 (type "ext4"))
   %base-file-systems))

I should make a note that I usually don't use efi, and I'm not
completely confident it's all set up properly. I do have a
"BIOS boot" partition on /dev/sda1 too, is that even needed with
efi? Although, I have been using this setup, and the above
definitions, for about 6 months now without any bootloader or
filesystem issues. And the same config is being used to fix the
system when GRUB breaks as well as to reconfigure afterward
(causing the breakage). So my guess is some new update is the
culprit.

bug#36931: guile-bash repository no longer exists?

[Jesse Gibbons]

On Mon, 2019-08-05 at 16:38 +0200, Ricardo Wurmus wrote:
> Jesse Gibbons  writes:
> 
> > guile-bash fails to build. The site https://anonscm.debian.org/cgit
> > /use
> > rs/kaction-guest/retired/dev.guile-bash.git says it is not on the
> > web
> > server.
> 
> Perhaps a copy of the sources can be found in the Software Heritage
> archive?
> 
> --
> Ricardo
> 

I don't know if it's exactly the same, but I found something similar at
https://archive.softwareheritage.org/browse/origin/https://github.com/k
action/guile-bash/directory/
Thanks for the suggestion.

I requested a tarball, and received this statement in the email:
"Please keep in mind that this link might expire at some point, in
which case you will need to request the bundle again."

Do you have any recommendations on where to host the tarball? If
necessary, I am willing to create a repository for the code on my
github.

bug#36931: guile-bash repository no longer exists?

[Björn Höfling]

On Mon, 05 Aug 2019 16:38:07 +0200
Ricardo Wurmus  wrote:

> Jesse Gibbons  writes:
> 
> > guile-bash fails to build. The site
> > https://anonscm.debian.org/cgit/use
> > rs/kaction-guest/retired/dev.guile-bash.git says it is not on the
> > web server.  
> 
> Perhaps a copy of the sources can be found in the Software Heritage
> archive?

This was already discussed in 

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33861
https://lists.gnu.org/archive/html/guix-devel/2019-04/msg00558.html
https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00234.html

This software is unmaintained and nobody is willing to maintain it.
If nobody complains, we should drop it from Guix.

Here is an archive of a git repository:

https://alioth-archive.debian.org/git/users/kaction-guest/retired/guile-bash.git.tar.xz

But it doesn't have any commit with id

1eabc563ca5692b3e08d84f1f0e6fd2283284469

which is the one we use in Guix.

I tried to download it from SWH, but it failed:

$ guix build -S --no-substitutes guile-bash
The following derivation will be built:
   
/gnu/store/vrw4yfy4ln6yvc3wwppw4bwiaxdzl4jp-guile-bash-0.1.6-0.1eabc56-checkout.drv
building 
/gnu/store/vrw4yfy4ln6yvc3wwppw4bwiaxdzl4jp-guile-bash-0.1.6-0.1eabc56-checkout.drv...
environment variable `PATH' set to 
`/gnu/store/q09sy224qnxrp982z4xfaxi19721mjx8-gzip-1.9/bin:/gnu/store/ipx79bfj2mrc8npj7s3qi3zri11jfhaw-tar-1.30/bin'
Initialized empty Git repository in 
/gnu/store/7p7mkiqv9ah6x0x20qzpas44sdf7jqkl-guile-bash-0.1.6-0.1eabc56-checkout/.git/
fatal: repository 
'https://anonscm.debian.org/cgit/users/kaction-guest/retired/dev.guile-bash.git/'
 not found
Failed to do a shallow fetch; retrying a full fetch...
fatal: repository 
'https://anonscm.debian.org/cgit/users/kaction-guest/retired/dev.guile-bash.git/'
 not found
git-fetch: 
'/gnu/store/04abn97vvc06c84pi8cb3lni9jyxfzmf-git-minimal-2.22.0/bin/git fetch 
origin' failed with exit code 128
Trying content-addressed mirror at berlin.guixsd.org...
Trying content-addressed mirror at berlin.guixsd.org...
Backtrace:
   4 (primitive-load "/gnu/store/ixb9ja1vxd46ydf83qbj9f3f6qz?")
In ./guix/swh.scm:
532:8  3 (call-with-temporary-directory #)
   552:10  2 (_ "/tmp/guix-build-guile-bash-0.1.6-0.1eabc56-checkout?")
In ./guix/build/utils.scm:
   778:22  1 (_)
In unknown file:
   0 (get-bytevector-n! #f #vu8(0 0 0 0 0 0 0 0 0 0 0 0 0 ?) ?)

ERROR: In procedure get-bytevector-n!:
In procedure get-bytevector-n!: Wrong type argument in position 1 (expecting 
open input port): #f
builder for 
`/gnu/store/vrw4yfy4ln6yvc3wwppw4bwiaxdzl4jp-guile-bash-0.1.6-0.1eabc56-checkout.drv'
 failed with exit code 1
build of 
/gnu/store/vrw4yfy4ln6yvc3wwppw4bwiaxdzl4jp-guile-bash-0.1.6-0.1eabc56-checkout.drv
 failed
View build log at 
'/var/log/guix/drvs/vr/w4yfy4ln6yvc3wwppw4bwiaxdzl4jp-guile-bash-0.1.6-0.1eabc56-checkout.drv.bz2'.
guix build: error: build of 
`/gnu/store/vrw4yfy4ln6yvc3wwppw4bwiaxdzl4jp-guile-bash-0.1.6-0.1eabc56-checkout.drv'
 failed


Maybe it is not part of SWH? Message could be nicer. Though when I'm
searching for individual files from above git repository, I can find
them in SWH:

https://archive.softwareheritage.org/browse/content/sha1_git:dded8caad51a40c90c763fcf23ad18522f0e90d8/
https://archive.softwareheritage.org/browse/content/44a728397230f178c02131a001c884808bcd2d39/

It would be interesting if I can go in SWH from a file to the full
repository. Does anyone know if that is possible?

Björn




pgpMb0DPC_AZd.pgp
Description: OpenPGP digital signature

bug#36896: [PATCH] added gsettings-desktop-schema to progragated inputs

[Tobias Geerinckx-Rice]

Martin, Ricardo,

I agree with Ricardo (here and in matters of fonts) that 
propagation is to be avoided at all reasonable costs, so…


Martin Becze 写道：
The terminator packagage propagates gsetting-desktop-schema as 
well

but maybe its also doing the wrong thing?


…that was a mistake, in retrospect, fixed in 
96681d4be101c771fafd4257aca471685119fedd.  

You can probably apply that same fix directly to Evolution.  There 
should be no need to propagate anything.


Thanks!

T G-R


signature.asc
Description: PGP signature

bug#36632: ungoogled-chromium needs font-gnu-freefont-ttf

[Ricardo Wurmus]

Hi Martin,

> ungoogled-chromium will crash until font-gnu-freefont-ttf is installed.

Thank you for reporting this problem and proposing a patch.

I’d prefer not to propagate any fonts.  Do you happen to know what the
mechanism underlying the fix is?  Why does this fix the problem?  Why
does it crash in the first place?

Is this at all related to a stale font cache, perhaps?

-- 
Ricardo

bug#36938: Website: Package list is not updated

[Hartmut Goebel]

The package list at http://guix.gnu.org/packages/ is not updated. It
still says:

[…] provides 9,789 packages […] (updated July 19, 2019).

-- 

Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#36896: [PATCH] added gsettings-desktop-schema to progragated inputs

[Martin Becze]

On 2019-08-05 07:40, Ricardo Wurmus wrote:
> Hi,
> 
> null  writes:
> 
>> ---
>>  gnu/packages/gnome.scm | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
>> index 3f7bbac214..c33653f361 100644
>> --- a/gnu/packages/gnome.scm
>> +++ b/gnu/packages/gnome.scm
>> @@ -8074,6 +8074,8 @@ generic enough to work for everyone.")
>> ("openldap" ,openldap)
>> ("webkitgtk" ,webkitgtk)
>> ("ytnef" ,ytnef)))
>> +(propagated-inputs
>> +   `(("gsettings-desktop-schemas" ,gsettings-desktop-schemas)))
>>  (home-page "https://gitlab.gnome.org/GNOME/evolution";)
>>  (synopsis "Manage your email, contacts and schedule")
>>  (description "Evolution is a personal information management application
> 
> Thank you for the patch.
> 
> I’m not sure this is the right thing to do.  I don’t think we ever
> propagate this package.  Instead we often wrap executables so that
> relevant environment variables are set.  Would this work in the case of
> Evolution as well?

The terminator packagage propagates gsetting-desktop-schema as well
https://github.com/guix-mirror/guix/blob/8126142baf2cadd7b0052ba7b1d0cd248c8cbc40/gnu/packages/gnome.scm#L8159-L8161

but maybe its also doing the wrong thing? I'll look in to how to wrap
the executable and see if that will work.

bug#36930: NSS 3.45 fails to build on armhf-linux

[Marius Bakke]

Mark H Weaver  writes:

> Earlier, I wrote:
>> For now, we could simply revert my commit that updates NSS to 3.45.
>> Although I mentioned in the commit log that it fixed some CVEs, I later
>> discovered that 3.44.1 includes fixes for the same CVEs.  NSS 3.44.1 was
>> the version of NSS in 'master' before my commit.
>
> I reverted it in commit 0fae1b6deeabe15fa8c0c1623b46c9b7f2814295 on the
> master branch.

Thanks!

NSS is still broken on 'staging', so this issue remains open.


signature.asc
Description: PGP signature

bug#36930: NSS 3.45 fails to build on armhf-linux

[Mark H Weaver]

Earlier, I wrote:
> For now, we could simply revert my commit that updates NSS to 3.45.
> Although I mentioned in the commit log that it fixed some CVEs, I later
> discovered that 3.44.1 includes fixes for the same CVEs.  NSS 3.44.1 was
> the version of NSS in 'master' before my commit.

I reverted it in commit 0fae1b6deeabe15fa8c0c1623b46c9b7f2814295 on the
master branch.

 Thanks,
   Mark

bug#22138: Search paths of dependencies are not honored

[Julien Lepiller]

Le 5 août 2019 18:23:55 GMT+02:00, Mark H Weaver  a écrit :
>Hi Julien,
>
>Julien Lepiller  writes:
>
>> Hi, I've been looking at our current code and would like to propose
>the
>> attached patch for that issue.
>>
>> From cfd2c229087166ab4cc0a9e2bdb72c8b393bcdd5 Mon Sep 17 00:00:00
>2001
>> From: Julien Lepiller 
>> Date: Thu, 1 Aug 2019 22:09:38 +0200
>> Subject: [PATCH] guix: Recursively honor search paths of
>dependencies.
>>
>> * guix/packages.scm (all-transitive-inputs)
>> (package-all-transitive-inputs)
>> (package-all-transitive-native-search-paths): New procedures.
>> * guix/profiles.scm (package->manifest-entry): Use
>> package-all-transitive-native-search-paths to generate manifest
>search
>> paths.
>
>As I recall this kind of solution has been proposed in the past and
>rejected.  It's a reasonable suggestion, but I personally think that it
>goes too far, because it would include a great many packages whose code
>is nowhere to be found in the resulting profile.  For example, it would
>include documentation generators used to build man pages, and the
>compilers that were used to build those documentation generators, etc,
>all the way back to the early bootstrap binaries.
>
>Having said this, I agree that there is a longstanding problem in Guix
>with search-paths not including enough packages in its calculation.
>We've known about this problem for a long time, but as far as I know we
>have not yet found a satisfactory solution.
>
>Our current hacky workaround for problems like this has been to set
>certain environment variables unconditionally in /etc/profile.  For
>example, you'll see that MANPATH, INFOPATH, XDG_DATA_DIRS,
>XDG_CONFIG_DIRS, XCURSOR_PATH, DICPATH, and GST_PLUGIN_PATH are all set
>there.  See 'operating-system-etc-service' in (gnu system) for the
>relevant code.
>
>At the very least, I think we should wait for input from Ludovic before
>applying anything along these lines.
>
>Anyway, thanks for looking into it and making the proposal.
>
>  Best,
>   Mark

Tgis patch doesn't add any dependency to any package, since it doesn't record 
any more stone paths than without. It indeed defines more variables than 
needed, but isn't that ok?

bug#22138: Search paths of dependencies are not honored

[Mark H Weaver]

Hi Julien,

Julien Lepiller  writes:

> Hi, I've been looking at our current code and would like to propose the
> attached patch for that issue.
>
> From cfd2c229087166ab4cc0a9e2bdb72c8b393bcdd5 Mon Sep 17 00:00:00 2001
> From: Julien Lepiller 
> Date: Thu, 1 Aug 2019 22:09:38 +0200
> Subject: [PATCH] guix: Recursively honor search paths of dependencies.
>
> * guix/packages.scm (all-transitive-inputs)
> (package-all-transitive-inputs)
> (package-all-transitive-native-search-paths): New procedures.
> * guix/profiles.scm (package->manifest-entry): Use
> package-all-transitive-native-search-paths to generate manifest search
> paths.

As I recall this kind of solution has been proposed in the past and
rejected.  It's a reasonable suggestion, but I personally think that it
goes too far, because it would include a great many packages whose code
is nowhere to be found in the resulting profile.  For example, it would
include documentation generators used to build man pages, and the
compilers that were used to build those documentation generators, etc,
all the way back to the early bootstrap binaries.

Having said this, I agree that there is a longstanding problem in Guix
with search-paths not including enough packages in its calculation.
We've known about this problem for a long time, but as far as I know we
have not yet found a satisfactory solution.

Our current hacky workaround for problems like this has been to set
certain environment variables unconditionally in /etc/profile.  For
example, you'll see that MANPATH, INFOPATH, XDG_DATA_DIRS,
XDG_CONFIG_DIRS, XCURSOR_PATH, DICPATH, and GST_PLUGIN_PATH are all set
there.  See 'operating-system-etc-service' in (gnu system) for the
relevant code.

At the very least, I think we should wait for input from Ludovic before
applying anything along these lines.

Anyway, thanks for looking into it and making the proposal.

  Best,
   Mark

bug#36876: guix system delete-generations removes custom boot menu entries

[Jakob L. Kreuze]

Hi Jesse,

Jesse Gibbons  writes:

> I dual-booted Guix with another gnu/linux-libre distro.
> My configuration includes the other distro in the grub menu. When I run
> "sudo guix system delete-generations" the changes to the grub menu drop
> the other distro with the older system generations of guix.
>
> My current work-around for this is to run "guix system reconfigure ..."
> which includes the boot menu entries specified in the configuration.

Thanks for reporting this; it's a rather serious issue. The problem lies
in the 'reinstall-bootloader' procedure. Chiefly, it uses the default
bootloader configuration for whatever it can find using
'lookup-bootloader-by-name' and generates menu entries for the
generations reachable from '%system-profile', which is quite a bit
different from how 'guix system reconfigure' produces the bootloader
configuration. It really isn't ideal. To quote a comment in
'system.scm': "[i]t will be enough to allow the system to boot."

I don't think this should be _too_ hard to fix. To me, parsing the
installed Grub configuration to get existing menu entries seems like a
logical step forward.

Thoughts from anyone else?

Regards,
Jakob


signature.asc
Description: PGP signature

bug#36930: NSS 3.45 fails to build on armhf-linux

[Mark H Weaver]

Hi Marius,

Marius Bakke  writes:

> On armhf-linux, 'nss' fails early in the build process due to an
> undefined reference to "PR_Assert":
>
> https://ci.guix.gnu.org/log/5cqmmjd9a8h05l8y352z1pq4mlyd6w21-nss-3.45
>
> This is almost certainly because of this upstream commit, which swaps
> out the curve25519 implementation for 32-bit ARM systems:
>
> https://hg.mozilla.org/projects/nss/rev/7b749ff400db3ecab87f394c091ea0831254e674
>
> There is some discussion about it in this ticket:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1550579
>
> I don't know how all those people were able to benchmark the change.
> Perhaps we are missing something in our build flags?
>
> With NSS 3.45 now in the 'master' branch, we should fix this issue
> quickly as armhf users are currently unable to update their systems.
>
> I filed an upstream ticket here, but no response yet:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1571316

For now, we could simply revert my commit that updates NSS to 3.45.
Although I mentioned in the commit log that it fixed some CVEs, I later
discovered that 3.44.1 includes fixes for the same CVEs.  NSS 3.44.1 was
the version of NSS in 'master' before my commit.

   Mark

bug#36912: JSON-related tests failing on latest master branch

[Brian Leung]

Got it, thanks for your response.

On Mon, Aug 5, 2019 at 3:24 PM Ricardo Wurmus  wrote:

>
> Brian Leung  writes:
>
> > For example, `make check TESTS="tests/swh.scm"` yields two failing tests.
> > Running one of the package-manager test suites (such as gem.scm)` will
> also
> > produce some failing tests.
>
> This is not actually a bug.
>
> We switched from Guile JSON 1.x to 3.x, which has a different
> intermediate representation for JSON data structures.
>
> swh.scm and all other modules have been modified, but when you run “guix
> environment guix” you still get an environment with Guile JSON 1.x.
> This leads to the test failure.
>
> This problem disappears when you run “guix environment guix --ad-hoc
> guile-json”; it will disappear when the “guix” package is upgraded to
> point to the latest version of Guile JSON.
>
> --
> Ricardo
>
>

bug#36878: guix system reconfigure broken

[Jakob L. Kreuze]

Hi ison and Ricardo,

Ricardo Wurmus  writes:

> ison  writes:
>
>> I made the mistake of rebooting my machine after I first got this
>> error, I thought perhaps it was benign. But when it came back up I
>> was dropped to a GRUB rescue shell with some error about
>> "grub_file_filters" being an unknown symbol.
>
> This eems unrelated. The problem sounds like GRUB and its modules
> aren’t found for some reason.

It is unrelated to this specific issue, but it still does sound like my
patch is the source of the problem. Would you be willing to open a
separate ticket for tracking this, ison?

>> When running grub commands like "insmod normal" would just repeat the error
>> or say command not found.
>> The only way I could think to repair it was to run the Guix install disk,
>> mount my partitions, and do another "guix init" which allows me to boot into
>> my machine again. However, when I run "guix pull" and then perform a
>> reconfigure I still keep seeing the same line:
>> shepherd: Evaluating user expression (let* ((services (map primitive-load 
>> (?))) # ?) ?)
>
> I reconfigured a workstation yesterday and also saw this line.  It does
> look like an error, but it seems to be completely harmless.  I could
> boot juts fine.  I suppose that’s just the part where new service
> definitions are loaded.
>
> The problem you’re seeing is unrelated to this output.

Yes, this output is normal. Shepherd loads service files by evaluating
Scheme expressions. I could have sworn that 'guix system reconfigure'
showed the same line prior to my patch.

ison -- I'm very sorry that you've had this experience. Would you be
willing to share the 'bootloader' field of your operating system
configuration so I can look into this?

Regards,
Jakob


signature.asc
Description: PGP signature

bug#36931: guile-bash repository no longer exists?

[Ricardo Wurmus]

Jesse Gibbons  writes:

> guile-bash fails to build. The site https://anonscm.debian.org/cgit/use
> rs/kaction-guest/retired/dev.guile-bash.git says it is not on the web
> server.

Perhaps a copy of the sources can be found in the Software Heritage
archive?

--
Ricardo

bug#36924: fixing GDM + GNOME Shell

[Ricardo Wurmus]

Efraim Flashner  writes:

> On Sun, Aug 04, 2019 at 11:00:41PM +0200, Ricardo Wurmus wrote:
>> Hi Guix,
>>
>> Today I again couldn’t log into my workstation after upgrading the
>> system.  I’m using GDM + GNOME Shell.
>>
>> At first GDM wouldn’t start.  I knew what to do: remove /var/lib/gdm,
>> because some state must have accumulated there.
>
> For this one can we create a single-shot service that, on reconfigure or
> boot, removes this directory and recreates it? In fact, it seems this is
> basically what Debian does¹.

I suggested as much earlier, but it seems like a hack.  Is this how
GNOME expects this state directory to be handled?  The fact that Debian
does this is reassuring (or not…), but I would very much like to avoid
adding even more hacks.

>> GDM came up after a reboot, but I still couldn’t log in.  Instead I was
>> thrown back to the login screen without any error message.  I looked in
>> ~/.cache/gdm/session.log for information, but it only told me that
>> gnome-shell was killed.  Thanks.
>>
>> After removing both .local/share and .cache out of the way I could log
>> in again.
>
> This part seems a little harder to automate. /etc/skel is only sourced
> when a user is created, so it's hard to make sweeping changes to help
> people in this case, if they even want automated help. I'm guessing
> making .cache/gdm(?) read-only would create other issues.

Does anyone know why this happens at all?  What are the cached data?
Can we do without?

>> What can we do to make GDM and GNOME Shell more reliable?
>
> Modify the logout scripts to remove a users' .cache file seems extreme.
> Some of the other options, such as removing and recreating directories
> would address other issues we've had (such as /var/cache/fontconfig).

In my opinion generating a global /var/cache/fontconfig should be
prevented; removing it seems again like an avoidable hack.

--
Ricardo

bug#36931: guile-bash repository no longer exists?

[Jesse Gibbons]

guile-bash fails to build. The site https://anonscm.debian.org/cgit/use
rs/kaction-guest/retired/dev.guile-bash.git says it is not on the web
server.

I checked the wayback machine, github, and gitlab for some sort of
backup, but have had no luck. Is there a trustworthy replacement
source? If not, I'm not sure we should keep the package.

bug#36912: JSON-related tests failing on latest master branch

[Ricardo Wurmus]

Brian Leung  writes:

> For example, `make check TESTS="tests/swh.scm"` yields two failing tests.
> Running one of the package-manager test suites (such as gem.scm)` will also
> produce some failing tests.

This is not actually a bug.

We switched from Guile JSON 1.x to 3.x, which has a different
intermediate representation for JSON data structures.

swh.scm and all other modules have been modified, but when you run “guix
environment guix” you still get an environment with Guile JSON 1.x.
This leads to the test failure.

This problem disappears when you run “guix environment guix --ad-hoc
guile-json”; it will disappear when the “guix” package is upgraded to
point to the latest version of Guile JSON.

-- 
Ricardo

bug#36930: NSS 3.45 fails to build on armhf-linux

[Marius Bakke]

Hello,

On armhf-linux, 'nss' fails early in the build process due to an
undefined reference to "PR_Assert":

https://ci.guix.gnu.org/log/5cqmmjd9a8h05l8y352z1pq4mlyd6w21-nss-3.45

This is almost certainly because of this upstream commit, which swaps
out the curve25519 implementation for 32-bit ARM systems:

https://hg.mozilla.org/projects/nss/rev/7b749ff400db3ecab87f394c091ea0831254e674

There is some discussion about it in this ticket:
https://bugzilla.mozilla.org/show_bug.cgi?id=1550579

I don't know how all those people were able to benchmark the change.
Perhaps we are missing something in our build flags?

With NSS 3.45 now in the 'master' branch, we should fix this issue
quickly as armhf users are currently unable to update their systems.

I filed an upstream ticket here, but no response yet:
https://bugzilla.mozilla.org/show_bug.cgi?id=1571316


signature.asc
Description: PGP signature

bug#36878: guix system reconfigure broken

[Ricardo Wurmus]

ison  writes:

> I made the mistake of rebooting my machine after I first got this error, I
> thought perhaps it was benign. But when it came back up I was dropped to a
> GRUB rescue shell with some error about "grub_file_filters" being an unknown
> symbol.

This eems unrelated.  The problem sounds like GRUB and its modules
aren’t found for some reason.

> When running grub commands like "insmod normal" would just repeat the error
> or say command not found.
> The only way I could think to repair it was to run the Guix install disk,
> mount my partitions, and do another "guix init" which allows me to boot into
> my machine again. However, when I run "guix pull" and then perform a
> reconfigure I still keep seeing the same line:
> shepherd: Evaluating user expression (let* ((services (map primitive-load 
> (?))) # ?) ?)

I reconfigured a workstation yesterday and also saw this line.  It does
look like an error, but it seems to be completely harmless.  I could
boot juts fine.  I suppose that’s just the part where new service
definitions are loaded.

The problem you’re seeing is unrelated to this output.

-- 
Ricardo

bug#36896: [PATCH] added gsettings-desktop-schema to progragated inputs

[Ricardo Wurmus]

Hi,

null  writes:

> ---
>  gnu/packages/gnome.scm | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index 3f7bbac214..c33653f361 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -8074,6 +8074,8 @@ generic enough to work for everyone.")
> ("openldap" ,openldap)
> ("webkitgtk" ,webkitgtk)
> ("ytnef" ,ytnef)))
> +(propagated-inputs
> +   `(("gsettings-desktop-schemas" ,gsettings-desktop-schemas)))
>  (home-page "https://gitlab.gnome.org/GNOME/evolution";)
>  (synopsis "Manage your email, contacts and schedule")
>  (description "Evolution is a personal information management application

Thank you for the patch.

I’m not sure this is the right thing to do.  I don’t think we ever
propagate this package.  Instead we often wrap executables so that
relevant environment variables are set.  Would this work in the case of
Evolution as well?

-- 
Ricardo

bug#36878: guix system reconfigure broken

[ison]

On Fri, Aug 02, 2019 at 11:11:31AM -0400, Jakob L. Kreuze wrote:
> The patch made it into master as 1db6f137d; thanks to Danny for signing
> off on it. Should we close this?

I'm still experiencing this issue. "guix describe" shows that I'm using
commit 35600cd which should be newer than the fix.

I made the mistake of rebooting my machine after I first got this error, I
thought perhaps it was benign. But when it came back up I was dropped to a
GRUB rescue shell with some error about "grub_file_filters" being an unknown
symbol.

When running grub commands like "insmod normal" would just repeat the error
or say command not found.
The only way I could think to repair it was to run the Guix install disk,
mount my partitions, and do another "guix init" which allows me to boot into
my machine again. However, when I run "guix pull" and then perform a
reconfigure I still keep seeing the same line:
shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) 
# ?) ?)

I've tried this on several occasions over the last few days with different
commits following the supposed fix, and it still keeps doing the same thing,
and every time I follow the reconfigure with a reboot GRUB is broken again.

bug#36924: fixing GDM + GNOME Shell

[Efraim Flashner]

On Sun, Aug 04, 2019 at 11:00:41PM +0200, Ricardo Wurmus wrote:
> Hi Guix,
> 
> Today I again couldn’t log into my workstation after upgrading the
> system.  I’m using GDM + GNOME Shell.
> 
> At first GDM wouldn’t start.  I knew what to do: remove /var/lib/gdm,
> because some state must have accumulated there.

For this one can we create a single-shot service that, on reconfigure or
boot, removes this directory and recreates it? In fact, it seems this is
basically what Debian does¹.

> 
> GDM came up after a reboot, but I still couldn’t log in.  Instead I was
> thrown back to the login screen without any error message.  I looked in
> ~/.cache/gdm/session.log for information, but it only told me that
> gnome-shell was killed.  Thanks.
> 
> After removing both .local/share and .cache out of the way I could log
> in again.

This part seems a little harder to automate. /etc/skel is only sourced
when a user is created, so it's hard to make sweeping changes to help
people in this case, if they even want automated help. I'm guessing
making .cache/gdm(?) read-only would create other issues.

> 
> This happens whenever I upgrade the system.  This makes the system
> rather frustrating to use.  I don’t know if booting into an older system
> generation would result in the same problem, but my guess is that it
> would because both GDM and GNOME Shell appear to be leaving some binary
> files behind that cause different versions to crash unceremoneously.
> 
> What can we do to make GDM and GNOME Shell more reliable?

Modify the logout scripts to remove a users' .cache file seems extreme.
Some of the other options, such as removing and recreating directories
would address other issues we've had (such as /var/cache/fontconfig).


¹ https://sources.debian.org/src/gdm3/3.30.2-3/debian/gdm3.postinst/#L76

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