bug#52585: lualatex: Unexpected non-option argument(s): lualatex.fmt

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Hello Sergiu, Hello Pāladhammika,

Em terça-feira, 28 de dezembro de 2021, às 09:16:32 -03, Sergiu Ivanov 
escreveu:
> Hello,
> 
> I am chiming in to say that I have the same issue.  In my case this
> doesn't seem related to https://issues.guix.gnu.org/51252 , because
> I install the entire texlive package.

I was able to reproduce the problem with the texlive package installed.
Installing the package texlive-latex-luatex doesn’t help.

I can work on this issue some days after the holidays.

Pāladhammika,

Just for clarification, do you also use entire texlive package?

-- 
Thanks,
Thiago

bug#52909: Some man pages are not built correctly

[Leo Famulari]

On Guix Git commit c7d74a9bccfc1b1274fc8754a6e78bb6887c7fea, at least
some manpages are not being built correctly for packages such as elogind
and gnome-keyring-daemon. Are we seeing raw groff input? I'm not sure of
the technology used here.

bug#52906: python-biopython conflicts with python-numpy

[Leo Famulari]

On Thu, Dec 30, 2021 at 10:13:48PM +0100, zimoun wrote:
> $ guix package -m /tmp/manifest.scm -p /tmp/fail
> The following packages will be installed:
>python-biopython 1.76
>python-numpy 1.21.3
> 
> guix package: error: profile contains conflicting entries for python-numpy
> guix package: error:   first entry: python-numpy@1.21.3 
> /gnu/store/ggrkk9l67fjn1cj7alr8vx40xv08a6h0-python-numpy-1.21.3
> guix package: error:   second entry: python-numpy@1.20.3 
> /gnu/store/wgsmkn68q8h178sqc7ywjcdr330z9rb6-python-numpy-1.20.3
> guix package: error:... propagated from python-biopython@1.76
> hint: Try upgrading both `python-numpy' and `python-biopython', or remove one 
> of
> them from the profile.
> --8<---cut here---end--->8---

See also ,
"tests/guix-pack-relocatable fails / numpy propagation collision".

> I propose to refer as name “python-numpy” the symbol python-numpy which
> leads to a consistent scientific Python stack.  And to refer as name
> “python-numpy-next” the symbol python-numpy-next.

Agreed, the stack should be kept consistent.

bug#52908: 'tests/guix-system.sh' fails on aarch64-linux

[Leo Famulari]

The Guix test 'tests/guix-system.sh' fails on aarch64-linux, like this:

--
+ for example in gnu/system/examples/*.tmpl
+ grep hurd  
+ echo gnu/system/examples/desktop.tmpl  
+ target=  
+ guix system -n disk-image gnu/system/examples/desktop.tmpl 
accepted connection from pid 23537, user nixbld 

guix system: warning: 'disk-image' is deprecated: use 'image' instead
spurious SIGPOLL   
spurious SIGPOLL 
spurious SIGPOLL 
guix system: error: service 'xorg-server' provided more than once   
+ rm -f t-guix-system-22708 t-guix-system-error-22708 
/tmp/guix-build-guix-1.3.0-17.2a49ddb.drv-0/t-guix-system-22708/config.scm 
/tmp/guix-build-guix-1.3.0-17.2a49ddb.drv-0/t-guix-system-22708
/my-torrc
+ rmdir /tmp/guix-build-guix-1.3.0-17.2a49ddb.drv-0/t-guix-system-22708
FAIL tests/guix-system.sh (exit status: 1)
--

This manifests while building the 'guix' package itself. Specifically
this derivation:

/gnu/store/i8rjwl9fmm4b6icvry8l2wlz2dwq09ic-guix-1.3.0-17.2a49ddb.drv

... which is based on commit 9f6532c77d35603f5e5d190616e0c6b1740e82bd:

https://ci.guix.gnu.org/build/251537/details

It doesn't happen on x86_64-linux:

https://ci.guix.gnu.org/build/251564/details

bug#52653: prusa-slicer fails build at configure

[Guillaume Le Vaillant]

Fixed by updating prusa-slicer to version 2.4.0 in commit
e0ef09a86c108805ae294fc0ce8d638e420f206d.


signature.asc
Description: PGP signature

bug#52906: python-biopython conflicts with python-numpy

[zimoun]

Hi,

Using 7022eb6, the package ’python-biopython’ propagates
’python-numpy’, i.e., python-numpy@1.20.3.

However, because Guix installs by default the last version and:

--8<---cut here---start->8---
$ guix package -A | grep 'python-numpy ' | cut -f1,2
python-numpy1.21.3  
python-numpy1.20.3  
--8<---cut here---end--->8---

then this manifests.scm leads to an error,

--8<---cut here---start->8---
$ cat /tmp/manifest.scm
(specifications->manifest
 (list "python-numpy"
   "python-biopython"))

$ guix package -m /tmp/manifest.scm -p /tmp/fail
The following packages will be installed:
   python-biopython 1.76
   python-numpy 1.21.3

guix package: error: profile contains conflicting entries for python-numpy
guix package: error:   first entry: python-numpy@1.21.3 
/gnu/store/ggrkk9l67fjn1cj7alr8vx40xv08a6h0-python-numpy-1.21.3
guix package: error:   second entry: python-numpy@1.20.3 
/gnu/store/wgsmkn68q8h178sqc7ywjcdr330z9rb6-python-numpy-1.20.3
guix package: error:... propagated from python-biopython@1.76
hint: Try upgrading both `python-numpy' and `python-biopython', or remove one of
them from the profile.
--8<---cut here---end--->8---

which is annoying.

I propose to refer as name “python-numpy” the symbol python-numpy which
leads to a consistent scientific Python stack.  And to refer as name
“python-numpy-next” the symbol python-numpy-next.

For instance, it is already the case for emacs-next or for the
Bioconductor package r-cistopic.

Doing so, adventurous people can use python-numpy-next (or recompile all
the scientific Python stack using it), or update it directly on master
(for testing say) without going to a core-update cycle.

WDYT?

Attached a proposed patch.

Cheers,
simon

>From 962d942ffcba7893ab15c30dc602e51462d9b09a Mon Sep 17 00:00:00 2001
From: zimoun 
Date: Thu, 30 Dec 2021 22:04:49 +0100
Subject: [PATCH] gnu: Rename last 'python-numpy' as 'python-numpy-next'.

* gnu/packages/python-xyz.scm (python-numpy-next): Rename.
---
 gnu/packages/python-xyz.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index 7ca0b1668d..047bb4cbb8 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -5366,11 +5366,9 @@ (define-public python2-cython
 ""))
  #t)
 
-;; NOTE: when upgrading numpy please make sure that python-pandas and
-;; python-scipy still build, as these three packages are often used together.
 (define-public python-numpy-next
   (package
-(name "python-numpy")
+(name "python-numpy-next")
 (version "1.21.3")
 (source
  (origin
@@ -5481,6 +5479,8 @@ (define-public python-numpy-1.20
  (substitute-keyword-arguments (package-arguments python-numpy-next)
((#:tests? _ #t) #f)
 
+;; NOTE: when upgrading numpy please make sure that python-pandas and
+;; python-scipy still build, as these three packages are often used together.
 (define-public python-numpy python-numpy-1.20)
 
 ;; NOTE: NumPy 1.8 is packaged only for Python 2 because it is of

base-commit: 002442b2209b0953dd209e6219696a8758ceceb2
-- 
2.34.0

bug#52831: [installer] Locale problems with nss-certs

[Mathieu Othacehe]

> Great, with your latest patch all seems to work well.
>
> The plan is to use wip-harden-installer for the release, right?

Yup, that's the plan :) In the meantime, I think we can close this one.

Thanks,

Mathieu

bug#52838: Guix Graphical Installation Crash

[Mathieu Othacehe]

Hey,

> Success! The installer successfully makes it through the partitioning
> step and generates a config file, and I am able to boot into the
> system.

Great, closing then!

Thanks,

Mathieu

bug#52904: nmtui - user authorisation

[raingloom]

On Wed, 29 Dec 2021 11:04:39 +
Paul Jewell  wrote:

> On 29/12/2021 00:50, raingloom wrote:
> > On Tue, 28 Dec 2021 18:39:52 +
> > Paul Jewell  wrote:
> >  
> >> On 27/12/2021 23:20, Leo Famulari wrote:  
> >>> On Mon, Dec 27, 2021 at 10:07:17PM +, Paul Jewell wrote:  
>  Solved this - nmtui needs to be run as root; my script which
>  invoked the program didn't consider that. Changing it to run as
>  sudo gives me an opportunity to enter my password, and then
>  successfully setup the wifi interface details.  
> >>> Another option is to add nmtui to the list of programs that are
> >>> setuid. That way, any user on your system could configure wifi,
> >>> which may be more ergonomic.
> >>>
> >>> https://guix.gnu.org/manual/devel/en/html_node/Setuid-Programs.html
> >>> 
> >> This option did work as expected. The only additional point for
> >> anyone else coming across this post with the same issue: remember
> >> to add the
> >>
> >> #:use-module (gnu system setuid)
> >>
> >> so the setuid record is known.
> >>
> >> Thanks Leo!  
> > Uhm, I'm pretty sure NetworkManager lets any user modify networking
> > settings as long as they are in a certain group?
> > https://wiki.archlinux.org/title/NetworkManager#Set_up_PolicyKit_permissions
> >
> > At least that's how it is on postmarketOS and I'm also fairly
> > certain I never needed root access to set up WiFi under Guix
> > either, but I don't have a system at hand to verify that on.  
> 
> I did also think this, but I couldn't identify which group would let 
> this happen. I thought it would be the netdev group, but my user
> account is already a member of that group. The network group is
> unknown to the system (as in I had an error when trying to add the
> user to the supplementary group) so I added it, but it didn't have
> any effect (after rebooting). If there is another group I should be
> in, I am not sure how to find out. At the moment, the setuid approach
> seems to work OK (although I would prefer a group solution!).
> 
> I am interested in anyone else's experience!

It might be that everyone else is including some default configuration
for NetworkManager and we aren't. At the very least it should be
documented how to set it up to use groups.

CC-ing bugs-guix 

bug#52838: Guix Graphical Installation Crash

[Joey Dunbar]

Hi Mathieu,
Success! The installer successfully makes it through the partitioning step
and generates a config file, and I am able to boot into the system.

Thanks!
Joey

On Tue, Dec 28, 2021, 10:02 AM Joey Dunbar  wrote:

> Hi Mathieu,
> I meant 1.3.0. I will try an install with the actual latest version and
> see what happens.
>
> Thanks!
>
> Joey
>
>
> On Tue, Dec 28, 2021, 2:03 AM Mathieu Othacehe  wrote:
>
>>
>> Hello Joey,
>>
>> Thanks for the complete bug report. When you say "most recent version",
>> do you mean the 1.3.0 release or the latest installer image available
>> here: https://guix.gnu.org/en/download/latest/?
>>
>> Mathieu
>>
>

bug#52831: [installer] Locale problems with nss-certs

[Leo Famulari]

On Thu, Dec 30, 2021 at 12:21:55PM +0100, Mathieu Othacehe wrote:
> Found why. Turns out installing the locale was preventing the cow-store
> umount. This is now fixed in the wip-harden-installer branch. The
> installer tests are passing, and I can use supported (fr_FR.utf8) and
> unsupported (en_AG.utf8) locales without hitting the nss-certs copy
> issue.

Great, with your latest patch all seems to work well.

The plan is to use wip-harden-installer for the release, right?

bug#52899: guix home configure with herd reconfigure bug

[Florian Hoertlehner]

I have a guix home configuration with herd services (mcron jobs).
When I run guix home reconfigure, and the user herd daemon is
running, then I get the following errors:

herd: exception caught while executing 'load' on service 'root':
In procedure fport_write: Broken pipe

When I run the SAME reconfigure command, but BEFORE running
it executing herd stop root. THEN I do not get this error, and the services
do appear correctly.

bug#52898: cmake-build-system keeps reference to native glibc in /etc/ld.so.cache

[Maxime Devos]

Hi,

cmake-build-system keeps a reference to the native glibc in
OUTPUT/etc/ld.so.cache, even when cross-compiling. Setting
#:make-dynamic-linker-cache? #false like in gnu-cross-build
would probably fix things. Other build systems might be
affected as well.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#52831: [installer] Locale problems with nss-certs

[Mathieu Othacehe]

> Oh right, system tests are failing here:
> https://ci.guix.gnu.org/eval/19842. Looks like the final umount fails,
> that's strange.

Found why. Turns out installing the locale was preventing the cow-store
umount. This is now fixed in the wip-harden-installer branch. The
installer tests are passing, and I can use supported (fr_FR.utf8) and
unsupported (en_AG.utf8) locales without hitting the nss-certs copy
issue.

Thanks,

Mathieu

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

[Ricardo Wurmus]

Mathieu Othacehe  writes:

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

I had the SAN slice extended from 5TB to 10TB.  This is now also full
(at 9.2TB due to SAN configuration).  I suggest doing the rsync to
Bordeaux from /mnt_test/var/cache/guix/publish instead of the much
slower /var/cache/guix/publish.  It doesn’t hold *all* files, but 9+TB
should be enough to fuel the transfer to Bordeaux for a while.

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

I don’t know.  I would want to take a copy of the root file system as a
backup of state (like the Lets Encrypt certs), and copy the closure of
the current operating system configuration somewhere.  We could copy it
to a dedicated build node (after stopping the GC cron job) and set it up
as an internal substitute server.  Then “guix system init” while
fetching the substitutes from that server.

But I guess we’d have to boot the installer image anyway so that we can
safely erase /gnu/store, or else we’d erase files that are currently in
use.

-- 
Ricardo

bug#52684: [BUG] Multiple Packages Failing to Build

[Maxime Devos]

Christopher Rodriguez schreef op ma 27-12-2021 om 13:18 [-0500]:
+  (native-search-paths
+   ;; XXX: Attempting to use (package-native-search-paths python)
here would
+   ;; cause an error about python being an unbound variable in the
+   ;; tests. Instead, we set and use an explicit python version.

This error doesn't have anything to do with profiles, but with import
cycles between modules and native-search-paths not being thunked.

+   (list
+    (search-path-specification
+ (variable "GUIX_BEETSPLUGINPATH")
+ (separator #f)
+ (files (list (string-append "lib/python" beets-python-version
"/site-packages"))

A downside of this approach, is that 'GUIX_BEETSPLUGINPATH' would
include unrelated python libraries. I don't know if this would be an
actual problem in practice. This could be resolved by installing beets
libraries to a non-standard location, say
"lib/beets-dependencies/site-packages".

The 'python-build-system' probably won't expect this, but that could be
resolved by adding things from "lib/beets-dependencies/site-packages"
to 'GUIX_PYTHONPATH' in a build phase.

Greetings,
Maxime


signature.asc
Description: This is a digitally signed message part

bug#52684: [BUG] Multiple Packages Failing to Build

[Maxime Devos]

Hi,

Christopher Rodriguez schreef op ma 27-12-2021 om 13:18 [-0500]:
> +  (let ((beets-python-version "3.9"))
> +    (package [...]))

I don't see the point of this 'let' form, because 'beets-python-
version' appears to be used only once below.

Greetings,
Maxime.



signature.asc
Description: This is a digitally signed message part

bug#52831: [installer] Locale problems with nss-certs

[Mathieu Othacehe]

Hey,

> But, now the installer always crashes at the end, after initializing the
> system on /mnt, when I "Press Enter to continue". A screenshot of the
> error message is attached. I can't scroll down to view more of it.

Oh right, system tests are failing here:
https://ci.guix.gnu.org/eval/19842. Looks like the final umount fails,
that's strange.

Mathieu

bug#51918: home-bash-service-type adds the defaults and aliases to the end of the file

[Andrew Tropin]

On 2021-12-19 09:45, Xinglu Chen wrote:

> Hi,
>
> On Wed, Nov 17 2021, Andrew Tropin wrote:
>
>> Test in guix-home.sh looks correct, but it fails:
>> https://git.savannah.gnu.org/cgit/guix.git/tree/tests/guix-home.sh?h=5eb5c0789f34e87ee417a53ddfcfa3b6521bb337#n98
>>
>> Seems something changed in home-bash-service-type, for some reason it
>> adds the serialized content of aliases field and guix-bashrc variable
>> after the content of bashrc field.
>
> This was changed in commit 2f665d4309053d5a9fe25bc93ee78d55dbc30cb7
> after discussing it with Liliana[1].  I didn’t really have a strong
> opinion on the order of the things; do you think that it should be changed?
>
> [1]: 

Seems Ludovic fixed it in c322d97832081e6e1913c6311616030d1fad4ee2, I
just had a slightly outdated local repository, when I was reporting this
bug, everything is ok now)

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

bug#48331: Emacs' describe-package doesn't work for packages managed by guix

[Andrew Tropin]

On 2021-12-03 21:46, Liliana Marie Prikler wrote:

> At long last, I'm pushing the patch to keep -pkg.el files as well as to
> load them from guix-emacs during package-initialize.  I'll hereby be
> closing this bug.  Andrew, if you wish to write a phase that adds such
> a file for the packages currently lacking them, I'm pretty sure we can
> do with a new bug number for that :)

I implemented this phase in issues.guix.gnu.org/52388, I have it applied
to my local guix fork and I didn't notice any issues with it, however,
emacs packages built without emacs-build-system will require tweaking.

Everyone reading this thread can jump to [1] and check it out =)

[1]: The mail thread id is 871r2mrleb@trop.in
>
> Thanks everyone involved for your help and patience.  Cheers
>

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature