bug#50433: shotcut 21.06.29 missing bin files

[Vinicius Monego]

Fixed in bc74c191df789ff200da6f81c3cf599eae39ca8e. Closing.

bug#52483: GnuPG 2.2.30 cannot do symmetric encryption

[Leo Famulari]

On Sun, Dec 19, 2021 at 03:36:25PM -0500, Leo Famulari wrote:
> On Sun, Dec 19, 2021 at 03:25:42PM -0500, Maxim Cournoyer wrote:
> > > I tested with GnuPG 2.2.23 by building all packages that depend directly
> > > on GnuPG. There were no new failures on x86_64-linux when using GnuPG
> > > 2.2.32.
> 
> I see that my message was confusing, with mixed up version numbers.
> There's no regressions on x86_64 with 2.2.32. Since it fixes this bug,
> I'd like to make it available soon. Maybe we can unhide the gnupg-2.2.32
> variable, and remove emacs-pinentry, since everyone is saying that it's
> no longer useful.

I pushed commit d03aa942d, which makes GnuPG 2.2.32 available in the UI.
I didn't remove emacs-pinentry... that's something that Emacs users
should decide how to handle.

bug#52807: Guix home executables are not executable

[Nick Zalutskiy]

Indeed I missed this in the manual. Thank you!

I was trying to figure out how to close this... no luck.

-Nick

On Sun, Dec 26, 2021, at 4:44 PM, Aleksandr Vityazev wrote:
> Hi,
>
> On 2021-12-26, 12:03 -0500, "Nick Zalutskiy"  wrote:
>
>>  I'd like to use `guix home` to symlink an executable into my home 
>> directory. 
>>
>>  Following simple configuration stored at 
>> `~/.dotfiles/home-configuration.scm`
>>
>>  (use-modules
>>(gnu home)
>>(gnu packages)
>>(gnu home services)
>>(gnu services)
>>(guix gexp)
>>(gnu home services shells))
>>
>>  (home-environment
>>(services
>>  (list (service
>>  home-bash-service-type
>>  (home-bash-configuration
>>(guix-defaults? #t)))
>>(simple-service 'my-files
>>home-files-service-type
>>`(("run" ,(local-file "run")))
>>
>>  `~/.dotfiles/run` is an executable file, after home reconfigure a 
>> `~/.run` symlink is created,
>>  however the file it is pointing to does _not_ have the execute bit set.
>>
>>  As a result, when I try to execute `~/.run` file I get a "Permission 
>> denied" error.
>>
>>  Thank you,
>>
>>  -Nick
>>
> In the Guix manual you can find the following information about
> local-file:
>
> --8<---cut here---start->8---
> -- Scheme Procedure: local-file FILE [NAME] [#:recursive? #f]
>   [#:select? (const #t)]
>  
> When RECURSIVE? is true, the contents of FILE are added
>  recursively; if FILE designates a flat file and RECURSIVE? is true,
>  its contents are added, and its permission bits are kept.
> --8<---cut here---end--->8---
>
> So you can just do this:
>
> #+begin_src scheme
> (simple-service 'my-files
> home-files-service-type
> `(("run" ,(local-file "run" #:recursive? #t
> #+end_src
>
> -- 
> Best regards,
> Aleksandr Vityazev

bug#52539: Fwd: Comments in /etc/passwd don't get updated

[Jacob First]

Thanks for the explanation. This rationale sounds reasonable to me. If
someone with proper permission has modified a user account's comment,
it could be important to preserve that customization.

As I pointed out in an earlier message, I believe this behavior
contradicts the documentation of the `user-account' data type pretty
strongly. So it appears there is at least a "doc bug" here.

FWIW, I actually reported the present behavior as a bug not because of
the doc issue, but based on an assumption that "purely declarative"
implied the result of applying a given configuration should not depend
on any preexisting system state like a user comment. Sorry for not
making that clear: it seemed obvious, but I think it's actually a
misconception (even if user accounts are one of the few areas, AFAICT,
where the property doesn't hold true).

On Wed, Dec 22, 2021 at 10:36 PM Ludovic Courtès  wrote:
>
> Hi,
>
> Jacob First  skribis:
>
> > After I apply this configuration with `guix system reconfigure', I
> > expect /etc/passwd to have been updated with "New Comment" in place of
> > "Old Comment". However, "Old Comment" remains.
>
> This is on purpose, per these lines in ‘allocate-passwd’ in (gnu build
> accounts):
>
>(real-name (if previous
>   (password-entry-real-name previous)
>   real-name))
>
> This wasn’t a firm decision, but I think the rationale here could be
> that we’d rather allow users to change their name with ‘chfn’ to
> something other than what the sysadmin chose, than enforce the
> sysadmin’s choice.  (Except that ‘chfn’ is currently not setuid by
> default on Guix System, so the scenario above is unlikely.)
>
> Thoughts?
>
> Thanks,
> Ludo’.

bug#52807: Guix home executables are not executable

[Aleksandr Vityazev]

Hi,

On 2021-12-26, 12:03 -0500, "Nick Zalutskiy"  wrote:

>  I'd like to use `guix home` to symlink an executable into my home 
> directory. 
>
>  Following simple configuration stored at 
> `~/.dotfiles/home-configuration.scm`
>
>  (use-modules
>(gnu home)
>(gnu packages)
>(gnu home services)
>(gnu services)
>(guix gexp)
>(gnu home services shells))
>
>  (home-environment
>(services
>  (list (service
>  home-bash-service-type
>  (home-bash-configuration
>(guix-defaults? #t)))
>(simple-service 'my-files
>home-files-service-type
>`(("run" ,(local-file "run")))
>
>  `~/.dotfiles/run` is an executable file, after home reconfigure a 
> `~/.run` symlink is created,
>  however the file it is pointing to does _not_ have the execute bit set.
>
>  As a result, when I try to execute `~/.run` file I get a "Permission 
> denied" error.
>
>  Thank you,
>
>  -Nick
>
In the Guix manual you can find the following information about
local-file:

--8<---cut here---start->8---
-- Scheme Procedure: local-file FILE [NAME] [#:recursive? #f]
  [#:select? (const #t)]
  
When RECURSIVE? is true, the contents of FILE are added
 recursively; if FILE designates a flat file and RECURSIVE? is true,
 its contents are added, and its permission bits are kept.
--8<---cut here---end--->8---

So you can just do this:

#+begin_src scheme
(simple-service 'my-files
home-files-service-type
`(("run" ,(local-file "run" #:recursive? #t
#+end_src

-- 
Best regards,
Aleksandr Vityazev

bug#52808: Guix home should not assume that all targets are dot files

[Nick Zalutskiy]

The following configuration results in a `~/.run` symlink being created. My 
expectation is that a `~/run` symlink is created instead. (ie. not a dotfile)

> (home-environment
>   (services
> (list (service
> home-bash-service-type
> (home-bash-configuration
>   (guix-defaults? #t)))
>   (simple-service 'my-files
>   home-files-service-type
>   `(("run" ,(local-file "run")))

This applies to all other targets. My expectation is that the configuration 
should expect the exact target and not make an assumption that all targets are 
hidden files, since that allows for more utility: 

> (home-environment
>   (services
> (list (service
> home-bash-service-type
> (home-bash-configuration
>   (guix-defaults? #t)))
>   (simple-service 'config-files
>   home-files-service-type
>   `(("run" ,(local-file "run"))
> ("README.txt" ,(local-file "README.txt"))
> (".config/guix/channels.scm" ,(local-file "config/guix
> (".emacs.d/init.el" ,(local-file "emacs.d/init.el"))
> (".vimrc" ,(local-file "vimrc"))
> (".gitconfig" ,(local-file "gitconfig")))

Thank you,

-Nick

bug#52807: Guix home executables are not executable

[Nick Zalutskiy]

I'd like to use `guix home` to symlink an executable into my home directory. 

Following simple configuration stored at `~/.dotfiles/home-configuration.scm`

> (use-modules
>   (gnu home)
>   (gnu packages)
>   (gnu home services)
>   (gnu services)
>   (guix gexp)
>   (gnu home services shells))
> 
> (home-environment
>   (services
> (list (service
> home-bash-service-type
> (home-bash-configuration
>   (guix-defaults? #t)))
>   (simple-service 'my-files
>   home-files-service-type
>   `(("run" ,(local-file "run")))

`~/.dotfiles/run` is an executable file, after home reconfigure a `~/.run` 
symlink is created, however the file it is pointing to does _not_ have the 
execute bit set.

As a result, when I try to execute `~/.run` file I get a "Permission denied" 
error.

Thank you,

-Nick

bug#52797: texlive broken install

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Michael,

Michael Zappa 写道：
I am currently on a foreign installation of Guix after some time 
on Guix
System, and did not appreciate that guix-daemon ran off of the 
root
user's guix. Simply running `guix pull` as root and restarting 
the

daemon fixed this issue.


\o/

I see Jéŕemy posted in the 'help' mail list for this issue, I 
will
consider that list for questions in the future. I am new to the 
mailing

list system.


I think either list is fine.  You encountered a real bug, after 
all; it's not your job to know it was ‘fixed’ or that it wasn't 
‘actually’ related to texlive at all.


Searching issues.guix.gnu.org for existing bug reports first is 
appreciated, but it's not always easy to guess which keywords to 
use.


Plus: closing bugs is fun.  Doing so now.

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#52797: texlive broken install

[Michael Zappa]

Thanks for the hint Tobias,

I am currently on a foreign installation of Guix after some time on Guix
System, and did not appreciate that guix-daemon ran off of the root
user's guix. Simply running `guix pull` as root and restarting the
daemon fixed this issue.

I see Jéŕemy posted in the 'help' mail list for this issue, I will
consider that list for questions in the future. I am new to the mailing
list system.

Thank you for your help,
Michael

bug#52801: Guile inconsistently misbehaves in case of escapes and carriage returns, breaking "guix pull"

[Maxime Devos]

retitle 52801 Guile inconsistently misbehaves in case of escapes and carriage 
returns, breaking "guix pull"
severity 52801 important
thanks

Grigory Shepelev schreef op zo 26-12-2021 om 13:14 [+0300]:
Today's guix pull gives the following bug.

Seems like an instance of .
I took the liberty of renaming the bug report appropriately.

Anyway, here's the minimal reproducer:

Run the following in a REPL:
(call-with-input-string "\"Hello\\\rcarriage return!\"" read)
;; --> invalid character in escape sequence: #\return

Greetings,
Maxime.

bug#52801: Bug report

[Grigory Shepelev]

Today's guix pull gives the following bug.
shegeley@zone51 ~$ guix pull
Updating channel 'nonguix' from Git repository at 
'https://gitlab.com/nonguix/nonguix'...
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from these channels:
  guix  https://git.savannah.gnu.org/git/guix.git   2495582
  nonguix   https://gitlab.com/nonguix/nonguix  39e4b41
Computing Guix derivation for 'x86_64-linux'... -ice-9/read.scm:126:4: In 
procedure read-string:
gnu/packages/virtualization.scm:640:1: invalid character in escape sequence: 
#\return
guix pull: error: You found a bug: the program 
'/gnu/store/w1hd6ab7f92y0f2r1ah4yyvi205a71bc-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"2495582e08cf411163f0799d290fda5101141949"; system: "x86_64-linux";
host version: "1dfe8c372163d481ebebb97dd3b4cafa49906b28"; pull-version: 1).
Please report the COMPLETE output above by email to .

shegeley@zone51 ~$ guix describe
Generation 1Dec 25 2021 11:29:17(current)
  guix 1dfe8c3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 1dfe8c372163d481ebebb97dd3b4cafa49906b28
  nonguix 39e4b41
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: 39e4b41e5f7277b8d58084cd7aff8edde71f6572

shegeley@zone51 ~$ guix home describe
Generation 7Dec 26 2021 12:06:08(current)
  file name: /var/guix/profiles/per-user/shegeley/guix-home-7-link
  canonical file name: /gnu/store/gs67wavx1yi8073j7ab89ld9fkkjqhc5-home
  channels:
nonguix:
  repository URL: https://gitlab.com/nonguix/nonguix
  branch: master
  commit: 39e4b41e5f7277b8d58084cd7aff8edde71f6572
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 1dfe8c372163d481ebebb97dd3b4cafa49906b28
  configuration file: 
/gnu/store/r7wlaf9pqmnrharqprvhwcsxbzylwqrl-configuration.scm

shegeley@zone51 ~$ guix system describe
Generation 12   Dec 25 2021 23:09:27(current)
  file name: /var/guix/profiles/system-12-link
  canonical file name: /gnu/store/cyr8pjabz8gj9a99wydqwrs1igkmzxk8-system
  label: GNU with Linux 5.15.11
  bootloader: grub-efi
  root device: UUID: b127a177-06dd-4c1d-8ddf-53a68170f1b6
  kernel: /gnu/store/hs0vfgmvpywdzv7b7q2vpw38y73d6vls-linux-5.15.11/bzImage
  channels:
nonguix:
  repository URL: https://gitlab.com/nonguix/nonguix
  branch: master
  commit: 39e4b41e5f7277b8d58084cd7aff8edde71f6572
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 1dfe8c372163d481ebebb97dd3b4cafa49906b28
  configuration file: 
/gnu/store/ha2hn9i7yd7hds9hsx1bv5jf90ibja51-configuration.scm

bug#52791: nextcloud-client not building on master

[Brice Waegeneire]

Hello Nicholas,

Nicholas von Klitzing  writes:

> Updating the package to 3.2.0 (the version where the PR was merged) solves
> the issue. This patch is attached.
>
> I'll see if I get to updating it to 3.4.1

> * gnu/packages/sync.scm (nextcloud-client): Update to 3.2.0.
> ---
>  gnu/packages/sync.scm | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Thank you for fixing that failing build, pushed as
27eb4ac9f506f9f06061d79548de5da53ac03bfa.

If you want to update it to it's latestet version, don't forget to run "guix
lint" on it and add your copyright to the file if it's a non trivial change.

Cheers,
- Brice

bug#51787: Disk performance on ci.guix.gnu.org

[Mathieu Othacehe]

Hello Ricardo,

> Should we attempt to overwrite /gnu/store and rely exclusively on
> substitutes from the cache?

Yes, I don't see any other options. Before that, what might be nice
could be:

1. Ensure that all Berlin /var/cache/guix/publish directory is
synchronized on Bordeaux. We are now at 117G out of X. We could then
start a publish server on Bordeaux. As Bordeaux is already part of the
default substitute servers list, the transition could be smooth I guess.

2. Determine what file-system out of ext4, btrfs and xfs could be the
most suitable for Berlin's /gnu/store. I'm running some tests on an old
HDD to try to determine the fragmentation impact on those
file-systems. We can of course choose to be conservative and go for ext4
that did the job until now.

Regarding the /gnu/store re-creation, I wonder how can we do it without
reinstalling completely Berlin. Maybe we could save the system store
closure somewhere and restore it on the shining new file-system?

Thanks,

Mathieu