bug#59279: Mpv also won't play video on Guix System

[Markus Nilsson]

I can confirm that on Guix System mpv also fails after the upgrade to 0.35
.

Mpv won't play videos but it can play audio in the terminal. When trying to
play videos it will give the following error:

"[vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device
[vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be
unavailable.
amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
amdgpu: amdgpu_device_initialize failed.
[vo/gpu] Failed to commit ModeSetting atomic request (-13)
[vo/gpu/opengl] Failed to set CRTC for connector 66: Permission denied
Error opening/initializing the selected video_out (--vo) device.
Video: no video

Exiting... (Errors when loading file)"

This also sometimes causes the desktop environment to crash and go to the
login screen.

A quick google search indicates that this seems to happen because mpv now
needs libxpresent to work with x11 (just like Jorge P. de Morais said above
):

Mpv Issue no.

10327

Arch Linux package mpv-git

Mpv Issue no. 9773


I would submit a patch to fix this if I was better at guile. Is someone out
there up to the task?

Cheers
Markus

bug#58858: Installation script fails on distributions that use busybox

[Maxim Cournoyer]

Hi,

conses  writes:

> Hi,
>
> Following the instructions in the manual, I attempted to install the
> package manager in Alpine Linux via the official installation
> script. However, after completing the first prompts I got the error
> "mktemp: (null): Invalid argument". Upon closer inspection of the script
> and busybox's `mktemp' help page, which states the following:
>
> TEMPLATE must end with XX (e.g. [/dir/]nameXX)
>
> It's clear that the script should be modified to account for this with
> at least 6 "X" characters in the template, and this wouldn't pose a
> problem with GNU's `mktemp' because it takes "at least" 3 of them.

Thanks for the investigation and solution.  Applied in 6aa5d1dc24, which
should now be live at https://guix.gnu.org/install.sh.

-- 
Thanks,
Maxim

bug#58606: Emacs next pgtk crashes when pasting to other app

[Joshua Branson via Bug reports for GNU Guix]

Declan Tsien  writes:

> Andrew Tropin  writes:
>
>> Recently discovered a problem, which reproduces this way:
>> - Open a new emacs instance.
>> - Yank anything with M-w or select with mouse.
>> - Paste yanked text to chromium/icecat.
>>
>> Both browser and emacs are hanging up for a while and after that Emacs
>> crashes with:
>

I just discovered today, that I can copy text from emacs and paste that
text into firefox.  It seems to no longer be an issue for me.  :)

bug#59196: guix pull fails on A20-OlinuXino-LIME2-eMMC

[Tanguy LE CARROUR]

Hi,


Quoting Tanguy LE CARROUR (2022-11-16 09:13:00)
> Quoting Denis 'GNUtoo' Carikli (2022-11-16 04:17:15)
> > I've found an idea: guix pull can pull to a precise commit:
> > >   --commit=COMMITdownload the specified "guix" channel COMMIT
> > 
> > So maybe it works with a commit close to Guix 1.3. If that's the case
> > we can probably bisect it to the commit that broke your guix pull.
> 
> Sounds like a good idea! I'll try that later today and let you know!

I bought a brand new "microSDHC UHS-1 A1" card and re-installed the
latest Armbian on it, and… I couldn't even test your idea, for `guix pull`
now fails with the following error message:

```
root@lime2:~# guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
guix pull: error: Git error: error inflating zlib stream
```

I tried again, but… it failed again! 

… so I tried with [the binary 
install](https://guix.gnu.org/manual/en/html_node/Binary-Installation.html)
of Guix, but it fails to install Guix, for the `/tmp` directory on Armbian
is too small! 

I thought installing Guix System on my Lime would be less… frustrating!
I think I'll redirect my energy to other tasks for the time being…

Any way, thanks for your time and help!


-- 
Tanguy

bug#59200: reproducibility

[Guillaume Le Vaillant]

ykonai  skribis:

> Hi,
>
> It turns out this was due to the fact that I had ironclad git cloned on
> my computer, which was accidentally visible via :tree in the ASDF
> configuration. ASDF detected that a different ironclad was used and
> tried to compile-file to the gnu/store. I thought it was guix-related
> since it did occur with both --pure and --container, but I was running
> it with the default cwd share on.
>
> Using --container --no-cwd is the solution to this problem. 

Ok. Closing.


signature.asc
Description: PGP signature

bug#59200: reproducibility

[ykonai via Bug reports for GNU Guix]

Hi,

It turns out this was due to the fact that I had ironclad git cloned on
my computer, which was accidentally visible via :tree in the ASDF
configuration. ASDF detected that a different ironclad was used and
tried to compile-file to the gnu/store. I thought it was guix-related
since it did occur with both --pure and --container, but I was running
it with the default cwd share on.

Using --container --no-cwd is the solution to this problem. 

bug#59277: Latest guix documentation - version number scrambled ?

[Sébastien FARGE]

I totally agree your more convulated solution.And thanks for the explanation, indeed.envoyé : 16 novembre 2022 à 10:06de : zimoun à : Sébastien FARGE , 59...@debbugs.gnu.orgobjet : Re: bug#59277: Latest guix documentation - version number scrambled ?Hi,On Tue, 15 Nov 2022 at 16:56, Sébastien FARGE  wrote:>>> A consequence is that all links using the version number are broken.>> For exemple, on the page : https://guix.gnu.org/en/manual/devel/en/html_node/USB-Stick-and-DVD-Installation.html#Copying-to-a-USB-Stick Indeed, but the image is not built for each commit. Well, I do not know>> if it is fixable – or if it makes sense to fix. It is the devel manual>> after all. ;-)Does a documentation with broken links makes sense ?The point is that the (devel) manual is referring to some release only URLs: https://ftp.gnu.org/gnu/guix/The images there are only updated when a new release is out. It is nota rolling-release URL updated by the CI but a very stable URL manuallyupdated (I guess).This URL in the manual is generated by@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso},where VERSION is from version.texi generated at compile-time, IIRC.The simplest is to add a warning note mentioning the issue and pointing to: https://guix.gnu.org/en/download/latest/A more convoluted solution would to introduce another version label asRELEASE-VERSION and use it in these places in the manual.Cheers,simon

bug#59200: reproducibility

[Guillaume Le Vaillant]

ykonai via Bug reports for GNU Guix  skribis:

> I can definitely consistently reproduce this issue. Maybe something in
> your filesystem could interfere with this? Try:
> guix shell sbcl sbcl-uuid --container -- sbcl --eval '(require :asdf)'
> --eval '(asdf:load-system :uuid)'
>
> This is on guix commit 8f9588185d74f1f251b041b84d43302c337588ff, which
> is from a fresh guix pull.
>
> I was wrong wrt. .fasl files missing: ls -l $(guix build
> sbcl-uuid)/lib/common-lisp/sbcl/uuid/ does show that the FASL is there,
> it is simply that SBCL arbitrarily decides it needs to be recompiled,
> which looks like the problem here. It could be some ASDF upstream bug.

I tried:

--8<---cut here---start->8---
guix time-machine --commit=8f9588185d74f1f251b041b84d43302c337588ff -- \
  shell sbcl sbcl-uuid --container -- \
  sbcl --no-userinit --eval '(require :asdf)' --eval '(asdf:load-system :uuid)'
--8<---cut here---end--->8---

and it worked without error.

Maybe there is something in your local CL configuration (.sbclrc) that
ASDF doesn't like...
Could you check if you still have an error when ignoring the local
configuration with:

--8<---cut here---start->8---
guix shell sbcl sbcl-uuid --container -- \
  sbcl --no-userinit --eval '(require :asdf)' --eval '(asdf:load-system :uuid)'
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#59277: Latest guix documentation - version number scrambled ?

[zimoun]

Hi,

On Tue, 15 Nov 2022 at 16:56, Sébastien FARGE  
wrote:

>>>  A consequence is that all links using the version number are broken.
>>>
>>>  For exemple, on the page : 
>>> https://guix.gnu.org/en/manual/devel/en/html_node/USB-Stick-and-DVD-Installation.html#Copying-to-a-USB-Stick
>>
>>  Indeed, but the image is not built for each commit. Well, I do not know
>>  if it is fixable – or if it makes sense to fix. It is the devel manual
>>  after all. ;-)
>
> Does a documentation with broken links makes sense ?

The point is that the (devel) manual is referring to some release only URLs:

https://ftp.gnu.org/gnu/guix/

The images there are only updated when a new release is out.  It is not
a rolling-release URL updated by the CI but a very stable URL manually
updated (I guess).

This URL in the manual is generated by

@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso},

where VERSION is from version.texi generated at compile-time, IIRC.

The simplest is to add a warning note mentioning the issue and pointing to:

https://guix.gnu.org/en/download/latest/

A more convoluted solution would to introduce another version label as
RELEASE-VERSION and use it in these places in the manual.


Cheers,
simon

bug#59278: how gcc-toolchain can depends a package who doesn't exists?

[zimoun]

Hi,

On Tue, 15 Nov 2022 at 22:42, bbb ee  wrote:

> It is just a little confusing for newcomers to guix. If we really want to
> improve something, I think that could be to give a more rigorous
> specification of the guix command:

I agree that the manual does not speak about the concept of
’hidden-package’, if I read correctly.  A note would be welcome, IMHO.

However, the commit you are referring is from 2020:

c81457a5883ea43950eb2ecdcbb58a5b144bcd11
Author: Ludovic Courtès 
AuthorDate: Fri May 8 16:34:58 2020 +0200
Commit: Ludovic Courtès 
CommitDate: Fri May 8 16:34:58 2020 +0200

gnu: gcc-toolchain: Add 10.1.0.

* gnu/packages/commencement.scm (gcc-toolchain-10): New variable.

1 file changed, 3 insertions(+)
gnu/packages/commencement.scm | 3 +++

and many things have been improved since. ;-)


For instance, using 00ff6f7 (from ~Oct 2022), it reads,

--8<---cut here---start->8---
$ guix search gcc | recsel -p name,version | head -30
name: gcc
version: 12.2.0

name: gcc
version: 11.3.0

name: gcc
version: 10.3.0

name: gcc
version: 9.5.0

name: gcc
version: 8.5.0

name: gcc
version: 7.5.0

name: gcc
version: 2.95.3

name: gcc-toolchain
version: 12.2.0

name: gcc-toolchain
version: 11.3.0

name: gcc-toolchain
version: 10.3.0
--8<---cut here---end--->8---

Wait, contrary to what I said, the packages are not hidden when they
should be!  For example, gcc@4m @5 and @6 are not displayed but @7 is.

--8<---cut here---start->8---
$ guix show gcc@6
guix show: error: gcc@6: package not found

$ guix show gcc@7
name: gcc
version: 7.5.0
outputs:
+ lib: shared libraries
+ debug: debug information
+ out: everything else
systems: x86_64-linux i686-linux
dependencies: gmp@6.2.1 isl@0.23 libelf@0.8.13 libstdc++-headers@10.3.0 
mpc@1.2.1 mpfr@4.1.0 perl@5.34.0 texinfo@6.7 zlib@1.2.11
location: gnu/packages/gcc.scm:601:2
homepage: https://gcc.gnu.org/
license: GPL 3+
synopsis: GNU Compiler Collection  
description: GCC is the GNU Compiler Collection.  It provides compiler 
front-ends for several languages, including C, C++, Objective-C, Fortran, Ada, 
and
+ Go.  It also includes runtime support libraries for these languages.
--8<---cut here---end--->8---

It is because the ’properties’ field of gcc@7 is rewritten,

--8<---cut here---start->8---
(define-public gcc-7
  (package
(inherit gcc-6)
(version "7.5.0")
[...]
(properties
 `((compiler-cpu-architectures
("aarch64" ,@%gcc-7.5-aarch64-micro-architectures)
("armhf" ,@%gcc-7.5-armhf-micro-architectures)
("x86_64" ,@%gcc-7.5-x86_64-micro-architectures))
--8<---cut here---end--->8---

and thus, it looses ’hidden’, as shown here:

--8<---cut here---start->8---
$ guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use(gnu packages gcc)
scheme@(guix-user)> (package-properties gcc-6)
$1 = ((hidden? . #t) (gcc-libc . #f))
scheme@(guix-user)> (package-properties gcc-7)
$2 = ((compiler-cpu-architectures ("aarch64" "armv8-a" "armv8.1-a" "armv8.2-a" 
"armv8.3-a") ("armhf" "armv7" "armv7-a" "armv7-m" "armv7-r" "armv7e-m" 
"armv7ve" "armv8-a" "armv8-a+crc" "armv8.1-a" "armv8.1-a+crc" "armv8-m.base" 
"armv8-m.main" "armv8-m.main+dsp" "iwmmxt" "iwmmxt2") ("x86_64" "core2" 
"nehalem" "westmere" "sandybridge" "ivybridge" "haswell" "broadwell" "skylake" 
"bonnell" "silvermont" "knl" "skylake-avx512" "k8" "k8-sse3" "barcelona" 
"bdver1" "bdver2" "bdver3" "bdver4" "znver1" "btver1" "btver2" "geode")))
scheme@(guix-user)>
--8<---cut here---end--->8---


Thanks, there is indeed a bug. ;-)


Back to the initial report, what could be improved is the display of the
field ’dependencies’; distinguishing regular packages to hidden ones.
And maybe instead of a plain error “package not found”, the command
“guix show” could error which “non installable package” or something
like that.


Cheers,
simon

bug#59196: guix pull fails on A20-OlinuXino-LIME2-eMMC

[Tanguy LE CARROUR]

Hi,


Quoting Denis 'GNUtoo' Carikli (2022-11-16 04:17:15)
> I've found an idea: guix pull can pull to a precise commit:
> >   --commit=COMMITdownload the specified "guix" channel COMMIT
> 
> So maybe it works with a commit close to Guix 1.3. If that's the case
> we can probably bisect it to the commit that broke your guix pull.

Sounds like a good idea! I'll try that later today and let you know!

Thanks,


-- 
Tanguy