bug#52682: installer freezes when ci.guix.gnu.org cannot be reached

2021-12-28 Thread Mathieu Othacehe


Hey Ricardo,

> address.  I forgot to add a line to /etc/hosts to resolve
> ci.guix.gnu.org to the local IP.  When I started the installation it
> would print two lines and then seemingly freeze.

I can replicate this issue in a VM, by disconnecting the host network in
the middle of the installation.

I can also replicate it by running a "guix system init
~/guix/gnu/system/examples/desktop.tmpl /tmp" and blocking Berlin IP
while the command is running, this way: "sudo iptables -A INPUT -s
141.80.181.40 -j DROP". The init command hangs forever.

So looks like the freeze issue goes beyond the installer frame and is
more a Guix issue.

In the meantime, we could also extend the installer connectivity check
to make sure that ci.guix.gnu.org is available before proceeding to the
installation.

Thanks,

Mathieu





bug#52838: Guix Graphical Installation Crash

2021-12-28 Thread Mathieu Othacehe


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#52845: guix init freezes when ci.guix.gnu.org is unavailable

2021-12-28 Thread Mathieu Othacehe


Hello,

This is a follow-up of the issue reported by Ricardo here:
https://issues.guix.gnu.org/52682.

When running this command:

--8<---cut here---start->8---
guix system init ~/guix/gnu/system/examples/desktop.tmpl /tmp
--8<---cut here---end--->8---

and simulating a connection loss, in the middle of its execution, this
way:

--8<---cut here---start->8---
sudo iptables -A INPUT -s 141.80.181.40 -j DROP
--8<---cut here---end--->8---

the init commands hangs forever. Looks like we are missing a timeout
somewhere.

Thanks,

Mathieu





bug#52840: cuirass/UI: don't use color as only source of information

2021-12-28 Thread Mathieu Othacehe


Hello,

> There is no reason to hide the text behind a hover action, especially
> since not all input devices support that.

That specific issue is fixed with:
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=d9a4ea25e4056f71b12d7d8869510793bab41674.

I'm sure there are possibly other accessibility issues, don't hesitate
to report them too.

Thanks,

Mathieu





bug#52846: Fetching "texlive" substitute from ci.guix.gnu.org fails

2021-12-28 Thread Konrad Hinsen
With

   $ guix describe
   Generation 11déc. 27 2021 11:45:02   (current)
 guix 879a5cb
   repository URL: https://git.savannah.gnu.org/git/guix.git
   branch: master
   commit: 879a5cb7c45779ddd62699ae2d75a9e785d608ec

do:

   $ guix shell texlive
   hint: Consider passing the `--check' option once to make sure your shell 
does not clobber environment variables.

   substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
   The following derivations will be built:
  /gnu/store/6z9arnfp3c51iq99wddcbcal9zbbayav-profile.drv
  /gnu/store/js6cv4h83n60k8kh9vcgy2k0syfqm5yv-texlive-texmf-20210325.drv
  
/gnu/store/z5r60zy9vmydf44fdyyc7hgc6q93aahm-texlive-20210325-texmf.tar.xz.drv

   0,7 MB will be downloaded
   guix shell: error: integer expected from stream

The same error is shown for other attempts to access "texlive",
e.g. "guix package". Disabling substitutes solves the problem, for those
who have the patience to wait for texlive to build locally.

Cheers,
  Konrad.





bug#52846: Fetching "texlive" substitute from ci.guix.gnu.org fails

2021-12-28 Thread Tobias Geerinckx-Rice via Bug reports for GNU Guix

Konrad,

Is this ?

Kind regards,

T G-R


signature.asc
Description: PGP signature


bug#52846: Fetching "texlive" substitute from ci.guix.gnu.org fails

2021-12-28 Thread Konrad Hinsen
Hi Tobias,

> Is this ?

Yes, same problem!

So... how did I overlook this when searching for "texlive" in the issue
tracker? Answer: it doesn't sort correctly by "date submitted" when that
column is selected. Issue 52797 is way down on the list.

Anyway, thanks for the pointer! I will try to update my daemon and see
what happens!

Cheers,
  Konrad





bug#52846: Fetching "texlive" substitute from ci.guix.gnu.org fails

2021-12-28 Thread Tobias Geerinckx-Rice via Bug reports for GNU Guix

Konrad Hinsen 写道:
So... how did I overlook this when searching for "texlive" in 
the issue
tracker? Answer: it doesn't sort correctly by "date submitted" 
when that

column is selected. Issue 52797 is way down on the list.


Hah!  It seems to be a simple alphabetical sort :-D

(Good luck),

T G-R


signature.asc
Description: PGP signature


bug#52682: installer freezes when ci.guix.gnu.org cannot be reached

2021-12-28 Thread Mathieu Othacehe


> In the meantime, we could also extend the installer connectivity check
> to make sure that ci.guix.gnu.org is available before proceeding to the
> installation.

There's a proposed patch here: 5bc897e0496ff415e653c509ca3b68466e0ed771.

Thanks,

Mathieu





bug#52837: Failed to compile rav1e which is dependence for tons of packages

2021-12-28 Thread Nicolas Goaziou
Hello,

Leo Famulari  writes:

> On Tue, Dec 28, 2021 at 02:09:42AM +0300, Evgenii Lepikhin via Bug reports 
> for GNU Guix wrote:
>> Hi there,
>> 
>> rav1e failed to compile with error:
>
> Alright, for now I've reverted the commits that caused the problem.
>
> Specifically, I reverted this range of commits:
> 5b1ec376239602725171d4523406801b684ee195^..13d3120095e4baa03594d095b0afe9febbb7cee0

Thank you.

You reverted 100+ commits but only one of them is problematic. Could you
unrevert them barring ad1e8a0906cca4f5c2fd18534a935a375161e608?

> IIUC, these were pushed together.
>
> Nicolas, can you take a look at the suggested fix shown below?

IIUC, a safe solution would be to exceptionally provide both
rust-dav1d-sys 0.3.2 (for rav1e) and 0.3.4 (for nushell), the latter
being called rust-dav1d-sys-0.3.

With this we do not have to bother updating rav1e yet.

WDYT?


Regards,
-- 
Nicolas Goaziou





bug#52834: sanity-check fails with namespace packages

2021-12-28 Thread Lars-Dominik Braun
Hi Hartmut,

> These fail due to sanity-check not being able to import "zope" - which 
> is a namespace package. Both use the "src directory layout" (source is 
> contained in a sub-directory "src").
As far as I see PEP 420 (implicit namespace packages) is supported by
Python >=3.3 only, so I’m not sure the packages would work even if we
disabled 'sanity-check, do they? Either way, I’m in favor of removing
broken Python 2 packages.

> This could be solved by fetching a list og namespace-packages and 
> checking whether a fails import is a namespace-package. Maybe there are 
> other solution.
> […]
>   nspkgs = set(dist.get_metadata_lines('namespace_packages.txt'))
Depending on undocumented setuptools behavior should imo be avoided and
– for top_level.txt – phased out if possible.

Cheers,
Lars






bug#52846: Fetching "texlive" substitute from ci.guix.gnu.org fails

2021-12-28 Thread Konrad Hinsen
Tobias Geerinckx-Rice  writes:

> Konrad Hinsen 写道:
>> So... how did I overlook this when searching for "texlive" in 
>> the issue
>> tracker? Answer: it doesn't sort correctly by "date submitted" 
>> when that
>> column is selected. Issue 52797 is way down on the list.
>
> Hah!  It seems to be a simple alphabetical sort :-D

Ah. April is always the most recent !

In the meantime, I confirm my problem goes away after updating the
daemon.

Thanks,
  Konrad





bug#52786: [aarch64] elogind 246.10 fails to start on ROCK64, breaking sway

2021-12-28 Thread pelzflorian (Florian Pelz)
elogind commit 7db52c01ed07f543f8272ea9a726cb542e771595 is the first
elogind version that does not launch, but it is too entangled to
simply revert.  I will take another look tomorrow.

On Sat, Dec 25, 2021 at 09:41:09AM +0100, pelzflorian (Florian Pelz) wrote:
> I shall try out if updating to
> 
> commit 488f1c589df00e802163af534294d93372e5c025
> services: dbus: Wait 1 minute for elogind to get ready.
> 
> helps, but the failure is immediate, so that is probably unrelated.

I have not yet tried because the check phase of the guix package had failed.

Regards,
Florian







bug#52838: Guix Graphical Installation Crash

2021-12-28 Thread Joey Dunbar
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#52847: Guitarix build fails

2021-12-28 Thread Demis Balbach

Hello, I'm currently unable to build `guitarix`. This only started
happening after the recent `core-updates-frozen` match, at least I
believe so.

--8<---cut here---start->8---
[ 485/1044] Compiling src/gx_head/engine/gx_preset.cpp
In file included from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/glib/gthread.h:32,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/glib/gasyncqueue.h:32,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/glib.h:32,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/glib/gi18n.h:21,
 from 
/gnu/store/c56vjl2qr5fsj3csn8l04zr91g3qpcaq-glibmm-2.64.5/include/glibmm-2.4/glibmm/i18n.h:23,
 from ../src/headers/engine.h:43,
 from ../src/gx_head/engine/gx_jack.cpp:30:
../src/headers/gx_system.h: In instantiation of ‘bool 
gx_system::atomic_compare_and_exchange(T**, T*, T*) [with T = 
_jack_session_event]’:
../src/gx_head/engine/gx_jack.cpp:1110:79:   required from here
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/glib/gatomic.h:202:45:
 error: invalid conversion from ‘volatile void*’ to ‘void*’ [-fpermissive]
  202 | __atomic_compare_exchange_n ((atomic), &gapcae_oldval, (newval), 
FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
  | ^
  | |
  | volatile void*
../src/headers/gx_system.h:135:12: note: in expansion of macro 
‘g_atomic_pointer_compare_and_exchange’
  135 | return g_atomic_pointer_compare_and_exchange(reinterpret_cast(p), static_cast(oldv), newv);
  |^

Waf: Leaving directory 
`/tmp/guix-build-guitarix-0.41.0.drv-0/guitarix-0.41.0/build'
Build failed
 -> task in 'guitarix' failed with exit status 1 (run with -v to display more 
information)
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "python" arguments: ("waf" "build") 
exit-status: 1 term-signal: #f stop-signal: #f>
phase `build' failed after 35.1 seconds
command "python" "waf" "build" failed with status 1
--8<---cut here---end--->8---

-- 
Best regards / Mit freundlichen Grüßen,
Demis Balbach


signature.asc
Description: PGP signature


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

2021-12-28 Thread Sergiu Ivanov
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.

How to reproduce: put these lines into test.tex (also attached for
convenience):

\documentclass{article}
\begin{document}
text
\end{document}

Run lualatex test.tex:

This is LuaTeX, Version 1.13.0 (TeX Live 2021/GNU Guix) 
 restricted system commands enabled.

kpathsea: Running mktexfmt lualatex.fmt
/gnu/store/irzhgvy2zb6dd9g7a6b343pn4lvsn9n0-texlive-bin-20210325/share/texmf-dist/scripts/texlive/fmtutil.pl:
 Unexpected non-option argument(s): lualatex.fmt
Try "fmtutil --help" for more information.
I can't find the format file `lualatex.fmt'!

Running pdflatex test.tex and xelatex test.tex works as expected.

-
Sergiu


test.tex
Description: TeX document


bug#52510: (no subject)

2021-12-28 Thread Florian
(specifications->manifest
 '("papirus-icon-theme"
   "breeze-icons"))

bug#52853: Error when trying to upgrade packages

2021-12-28 Thread Cameron Chaparro
I'm trying to run "guix upgrade" but I keep getting the following error:

guix upgrade: error: integer expected from stream

I found this bug (https://issues.guix.gnu.org/51983) that seems like it
could be related but it's happening as a result of querying bordeaux.guix
rather than ci.guix, in my case.

That said, I'm still relatively new to Guix (and haven't used Nix before)
so I could be wrong. Is there any chance someone could help me with this?
If there's something I can fix, please let me know and I'll look into it.

Thanks!

Cameron


bug#52853: Error when trying to upgrade packages

2021-12-28 Thread Tobias Geerinckx-Rice via Bug reports for GNU Guix

Cameron,

Cameron Chaparro 写道:

guix upgrade: error: integer expected from stream


Please upgrade and restart your guix-daemon and try again: 
https://issues.guix.gnu.org/52797


Kind regards,

T G-R


signature.asc
Description: PGP signature


bug#52837: Failed to compile rav1e which is dependence for tons of packages

2021-12-28 Thread Leo Famulari
On Tue, Dec 28, 2021 at 02:46:23PM +0100, Nicolas Goaziou wrote:
> You reverted 100+ commits but only one of them is problematic. Could you
> unrevert them barring ad1e8a0906cca4f5c2fd18534a935a375161e608?

I did so like this:

`git cherry-pick 
5b1ec376239602725171d4523406801b684ee195^..13d3120095e4baa03594d095b0afe9febbb7cee0
 && \
git revert ad1e8a0906cca4f5c2fd18534a935a375161e608`

Then, rav1e (and FFmpeg) built successfully.

So, I pushed as 9309b488ca4ceef4fcc9283546e3b05c57b16ca8.

> IIUC, a safe solution would be to exceptionally provide both
> rust-dav1d-sys 0.3.2 (for rav1e) and 0.3.4 (for nushell), the latter
> being called rust-dav1d-sys-0.3.
> 
> With this we do not have to bother updating rav1e yet.
> 
> WDYT?

Sounds like a plan. Are you able to do it?





bug#52837: We need deeper research

2021-12-28 Thread Leo Famulari
On Tue, Dec 28, 2021 at 09:01:07AM +0300, Evgenii Lepikhin via Bug reports for 
GNU Guix wrote:
> Hi,
> 
> Suggested fix is insufficient because dependency on version is hard coded in 
> the crate: 
> https://github.com/rust-av/aom-rs/blob/ea9a45d6ec7bfd2cd0d6f9f43268d9e379bba168/aom-sys/Cargo.toml#L18
> 
> We need to update both rust-aom-sys to == 0.3.0 and rav1e to >= 0.5.0.

Okay, that's good to know. I hope that somebody will try it and report
back.





bug#52837: Failed to compile rav1e which is dependence for tons of packages

2021-12-28 Thread Nicolas Goaziou
Hello,

Leo Famulari  writes:

> So, I pushed as 9309b488ca4ceef4fcc9283546e3b05c57b16ca8.

Thanks!
>
>> IIUC, a safe solution would be to exceptionally provide both
>> rust-dav1d-sys 0.3.2 (for rav1e) and 0.3.4 (for nushell), the latter
>> being called rust-dav1d-sys-0.3.
>> 
>> With this we do not have to bother updating rav1e yet.
>> 
>> WDYT?
>
> Sounds like a plan. Are you able to do it?

This is now done on master. AFAICT both nushell and rav1e build. I'll
let the OP confirm the issue is fixed and close the bug report.

Regards,
-- 
Nicolas Goaziou





bug#50140: [core-updates] test failures

2021-12-28 Thread Leo Famulari
core-updates has been merged and these test results cannot be reproduced
now.





bug#52859: tests/guix-pack-relocatable fails / numpy propagation collision

2021-12-28 Thread Leo Famulari
On commit 0d9d151424ab5823e441f056237819277b8aa072, the test
tests/guix-pack-relocatable fails on Debian due to a failure to build
a profile, because of a profile collision involving propagation of
numpy:

--
FAIL: tests/guix-pack-relocatable
=

accepted connection from pid 787596, user leo
accepted connection from pid 787606, user leo
+ guix pack --version
guix pack (GNU Guix) UNKNOWN
Copyright (C) 2021 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. 
++ guile -c '(use-modules (guix config))(display %storedir)'
+ storedir=/gnu/store
++ guile -c '(use-modules (guix config))(display %localstatedir)'
+ localstatedir=/var
+ NIX_STORE_DIR=/gnu/store
+ GUIX_DAEMON_SOCKET=/var/guix/daemon-socket/socket
+ export NIX_STORE_DIR GUIX_DAEMON_SOCKET
+ guile -c '(use-modules (guix)) (exit (false-if-exception (open-connection)))'
++ mktemp -d
+ test_directory=/tmp/tmp.isupVmMmSN
+ export test_directory
+ trap 'chmod -Rf +w "$test_directory"; rm -rf "$test_directory"' EXIT 
+ unshare -r true 
++ guix pack -R -S /Bin=bin sed
substitute: ^Msubstitute: ^[[Kupdating substitutes from 
'https://4606.nsupdate.info'...   0.0%^Msubstitute: ^[[Kupdating substitutes 
from 'https://4606.nsupdate.info'...  12.5%^Msubstitute: ^[[Kupdating 
substitutes from 'https://4606.nsupdate.info'...  25.0%^Msubstitute: 
^[[Kupdating substitutes from 'https://4606.nsupdate.info'...  
37.5%^Msubstitute: ^[[Kupdating substitutes from 
'https://4606.nsupdate.info'...  50.0%^Msubstitute: ^[[Kupdating substitutes 
from 'https://4606.nsupdate.info'...  62.5%^Msubstitute: ^[[Kupdating 
substitutes from 'https://4606.nsupdate.info'...  75.0%^Msubstitute: 
^[[Kupdating substitutes from 'https://4606.nsupdate.info'...  
87.5%^Msubstitute: ^[[Kupdating substitutes from 
'https://4606.nsupdate.info'... 100.0%
The following derivations will be built:
   /gnu/store/7qiyq9p2spfhfapl30dlsg15nhbllk0s-sed-tarball-pack.tar.gz.drv
   /gnu/store/lib6lf999nxjq23s0d87qq7k0wbxyrw6-profile.drv

0.3 MB will be downloaded
[... thousands of lines of building ...]
+ guix pack -RR python-numpy python-scipy --no-grafts -n
guix pack: error: profile contains conflicting entries for python-numpy
guix pack: error:   first entry: python-numpy@1.21.3 
/gnu/store/9dd0zkkwl45rmsa7b6vjb1747l57aw4y-python-numpy-1.21.3R
guix pack: error:   second entry: python-numpy@1.20.3 
/gnu/store/mlccgh05bf8cdinq0ilpvpdmsspq36pv-python-numpy-1.20.3R
guix pack: error:... propagated from python-matplotlib@3.4.3
guix pack: error:... propagated from python-scipy@1.7.3
hint: Backtrace:
In guix/gexp.scm:
   1180:2 19 (_ _)
   1046:2 18 (_ _)
892:4 17 (_ _)
In guix/store.scm:
  2008:12 16 (_ #)
   1385:9 15 (map/accumulate-builds # ?)
   1320:8 14 (call-with-build-handler # ?)
  2123:24 13 (run-with-store # ?)
In guix/gexp.scm:
   897:13 12 (_ _)
In guix/store.scm:
   1960:8 11 (_ _)
In guix/gexp.scm:
   296:22 10 (_ _)
In guix/profiles.scm:
   1878:2  9 (_ _)
358:4  8 (_ _)
In guix/store.scm:
   1869:0  7 (loop _ _)
In ice-9/boot-9.scm:
  1685:16  6 (raise-exception _ #:continuable? _)
  1685:16  5 (raise-exception _ #:continuable? _)
In guix/ui.scm:
   761:16  4 (_ _)
   314:42  3 (display-hint "Try upgrading both @code{python-numpy} ?" ?)
In ice-9/boot-9.scm:
  1747:15  2 (with-exception-handler # ?)
In guix/build/syscalls.scm:
  2282:35  1 (_)
   2271:8  0 (terminal-window-size _)

guix/build/syscalls.scm:2271:8: In procedure terminal-window-size:
In procedure terminal-window-size: Inappropriate ioctl for device
+ chmod -Rf +w /tmp/tmp.isupVmMmSN
+ rm -rf /tmp/tmp.isupVmMmSN
FAIL tests/guix-pack-relocatable.sh (exit status: 1)
--





bug#52837: Failed to compile rav1e which is dependence for tons of packages

2021-12-28 Thread Leo Famulari
On Tue, Dec 28, 2021 at 09:31:19PM +0100, Nicolas Goaziou wrote:
> This is now done on master. AFAICT both nushell and rav1e build. I'll
> let the OP confirm the issue is fixed and close the bug report.

Thanks!

I noticed that Guix complained about "possibly undefined variables" for
llvm and clang and rust-dav1d-sys-0.3.2 failed to build, so I pushed a
commit that imports the LLVM module in (gnu package video).

At first I was confused because rav1e still built, but our Rust
packaging doesn't require dependencies to build.





bug#35532: guix-daemon was freezed

2021-12-28 Thread Tobias Geerinckx-Rice via Bug reports for GNU Guix

Maxim Cournoyer 写道:

Closing, 2 years and 32 weeks later without a reply.


This might be tracked as  now 
(although we'll never know for sure).


Kind regards,

T G-R


signature.asc
Description: PGP signature


bug#46413: tests/publish.scm fails on berlin

2021-12-28 Thread Leo Famulari
On Wed, Feb 10, 2021 at 12:41:23AM +0100, zimoun wrote:
> On Wed, 10 Feb 2021 at 00:21, Leo Famulari  wrote:
> >
> > I notice that tests/publish.scm crashes consistently when run "by hand"
> > with `make check` on ci.guix.gnu.org:

This is still happening.





bug#41120: uvesafb service is unsupported on aarch64

2021-12-28 Thread Leo Famulari
On Thu, May 07, 2020 at 08:40:15AM +0300, Efraim Flashner wrote:
> the uvesafb-service which was added to the installation image isn't
> supported on aarch64 (or probably any non-x86 system) and causes the
> creation of an installation image to fail.

This is still an issue, right?