bug#45856:

Yes that's right. I'd better work with the shadowsocks-rust or new packages... Thank you.

bug#45856: Done

Done

bug#45895: Channel authentication should start at the current commit(s)

Hi! Currently, the first ‘guix pull’ (when ~/.cache/guix is empty) authenticates starting from the introductory commit. For the ‘guix’ channel, that’s 11K commits today, which takes about a minute to process on modern hardware. Authentication should instead consider the current commits, as retur

bug#45896: Non-pull ‘guix’ should know its channels

Related to , we have the problem that the ‘guix’ command coming from the ‘guix’ package doesn’t know its provenance: ‘guix describe’ errors out. We should fix it by storing a meta-data file within the ‘guix’ package. Likewise, on foreign distros, /usr/local/bin/

bug#45901: GNOME Fonts takes about 20 seconds to display fonts

## Steps to reproduce The following steps assume you are using Guix System with GNOME desktop. 1. Open the command prompt (ALT+F2) 2. Run gnome-font-viewer ## Expected result GNOME Fonts starts and displays the fonts available (system and user fonts?) with their corresponding names and thumbn

bug#45448: Emacs can't load org mode after last update

Pierre Langlois writes: > Great! I've just pushed with commit > cd11f6a2bd703f0859aec05c0873186b734d6d74, adding a comment to remove > this phase when the issue is resolved upstream. I think, with this commit, this can be closed. signature.asc Description: PGP signature

bug#45909: rust@1.47.0, rust-1.48.0 and rust-1.49.0 broken

The recent llvm 11.0.0 -> 11.0.1 change seems to have broken rust on the master branch.

bug#45909: rust@1.47.0, rust-1.48.0 and rust-1.49.0 broken

On Fri, Jan 15, 2021 at 11:50:13PM +, Christopher Baines wrote: > The recent llvm 11.0.0 -> 11.0.1 change seems to have broken rust on the > master branch. If anyone is wondering why we didn't notice failures of packages that depend on rust, the canonical 'rust' packages is rust-1.45, but thes

bug#45911: authorized-fields is not/badly documented

guix archive --authorize started issuing a warning some time ago pointing to "authorized-keys" in "operating-system". * that is not a valid field of operating-system * there is no such item in the Guix info page's index * the relevant example loads a single key from a file, without indicating wh

bug#45911: authorized-fields is not/badly documented

raingloom writes: > guix archive --authorize started issuing a warning some time ago > pointing to "authorized-keys" in "operating-system". > > * that is not a valid field of operating-system That’s right. It’s a field of guix-configuration, which is documented in 10.8.1 Base Services. -- R