bug#59299: Sequoia OpenPGP (libsequoia) build fails

[Philip McGrath]

The Sequoia OpenPGP packages are failing to build due to an error while
building libsequoia. Here's the tail of the build log; I've attached the full
log:

---8<---cut here---start->8---
   Compiling openssl-macros v0.1.0
   Compiling sequoia-ffi-macros v0.22.0 
(/tmp/guix-build-libsequoia-0.22.0.drv-0/source/ffi-macros)
error[E0659]: `parse_quote_spanned` is ambiguous
   --> 
/tmp/guix-build-libsequoia-0.22.0.drv-0/source/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/pin_project/derive.rs:859:67
|
859 | 
proj_generics.make_where_clause().predicates.push(parse_quote_spanned! { span =>
|   
^^^ ambiguous name
|
= note: ambiguous because of a conflict between a `macro_rules` name and a 
non-`macro_rules` name from another module
note: `parse_quote_spanned` could refer to the macro defined here
   --> 
/tmp/guix-build-libsequoia-0.22.0.drv-0/source/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/utils.rs:22:1
|
22  | / macro_rules! parse_quote_spanned {
23  | | ($span:expr => $($tt:tt)*) => {
24  | | syn::parse2(quote::quote_spanned!($span => 
$($tt)*)).unwrap_or_else(|e| panic!("{}", e))
25  | | };
26  | | }
| |_^
note: `parse_quote_spanned` could also refer to the macro imported here
   --> 
/tmp/guix-build-libsequoia-0.22.0.drv-0/source/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/pin_project/derive.rs:7:5
|
7   | *,
| ^
= help: use `self::parse_quote_spanned` to refer to this macro unambiguously

error[E0659]: `parse_quote_spanned` is ambiguous
   --> 
/tmp/guix-build-libsequoia-0.22.0.drv-0/source/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/pinned_drop.rs:108:21
|
108 | *path = parse_quote_spanned! { path.span() =>
| ^^^ ambiguous name
|
= note: ambiguous because of a conflict between a `macro_rules` name and a 
non-`macro_rules` name from another module
note: `parse_quote_spanned` could refer to the macro defined here
   --> 
/tmp/guix-build-libsequoia-0.22.0.drv-0/source/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/utils.rs:22:1
|
22  | / macro_rules! parse_quote_spanned {
23  | | ($span:expr => $($tt:tt)*) => {
24  | | syn::parse2(quote::quote_spanned!($span => 
$($tt)*)).unwrap_or_else(|e| panic!("{}", e))
25  | | };
26  | | }
| |_^
note: `parse_quote_spanned` could also refer to the macro imported here
   --> 
/tmp/guix-build-libsequoia-0.22.0.drv-0/source/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/pinned_drop.rs:3:50
|
3   | use syn::{spanned::Spanned, visit_mut::VisitMut, *};
|  ^
= help: use `self::parse_quote_spanned` to refer to this macro unambiguously

For more information about this error, try `rustc --explain E0659`.
error: could not compile `pin-project-internal` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
error: build failed
make: *** [Makefile:61: build-release] Error 101
make: Leaving directory '/tmp/guix-build-libsequoia-0.22.0.drv-0/source/ffi'
error: in phase 'build': uncaught exception:
%exception #< program: "make" arguments: ("-C" "ffi" 
"build-release") exit-status: 2 term-signal: #f stop-signal: #f> 
phase `build' failed after 181.5 seconds
command "make" "-C" "ffi" "build-release" failed with status 2
builder for `/gnu/store/lsj2mq9lbfs60f6wfi9ixrbajfvr7p9s-libsequoia-0.22.0.drv' 
failed with exit code 1
build of /gnu/store/lsj2mq9lbfs60f6wfi9ixrbajfvr7p9s-libsequoia-0.22.0.drv 
failed
View build log at 
'/var/log/guix/drvs/ls/j2mq9lbfs60f6wfi9ixrbajfvr7p9s-libsequoia-0.22.0.drv.bz2'.
cannot build derivation 
`/gnu/store/bcvm7b85cdqv68dx843mrs782a1s03ij-sequoia-1.6.0.drv': 1 dependencies 
couldn't be built
guix build: error: build of 
`/gnu/store/bcvm7b85cdqv68dx843mrs782a1s03ij-sequoia-1.6.0.drv' failed
---8<---cut here---end--->8---

If I understand https://ci.guix.gnu.org/build/1330033/details correctly, it
seems like the build has been failing for this reason since at least
September 5, though it succeeded September 1. I encountered the error using:

---8<---cut here---start->8---
philip@bastet:~$ guix describe --format=channels
(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch "master")
(commit
  "5512915c3bd62e061bd47d440da02e0826c1d0e7")
(introduction
  (make-channel-introduction
"9edb3f66fd807b096b48283debdcddccfea34bad"
(openpgp-fingerprint
  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")
---8<---cut here---end--->8---

-Philip

ls-j2mq9lbfs60f6wfi9ixrbajfvr7p9s-libsequoia-0.22.0.drv.bz2

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

[Denis 'GNUtoo' Carikli]

Hi,

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.

Denis.


pgp57F6DHZXlH.pgp
Description: OpenPGP digital signature

bug#59292: libreoffice password protection doesn't work

[Maxim Cournoyer]

Hi,

When password-protecting (encrypting) a file with LibreOffice, it fails
silently, leaving the file unprotected (!).

Reproducer:

1. Launch Calc with 'libreoffice --calc'.
2. Input something in the first cell.
3. Select File -> Save As.  At the bottom left of the dialog box, make
sure to tick the "Save with password" box.  Give it a name,
e.g. very-secret.ods, then click on "Save".
4. Enter a dummy password, such as 1234.
5. Quit LibreOffice Calc.

6. Open the assumed protected file, with 'libreoffice --calc
very-secret.ods'.  Notice the file is open without any password.

No output is printed at the console, and if you have an truly
password-encrypted file, it won't be able to open it.

-- 
Thanks,
Maxim

bug#59200: reproducibility

[ykonai via Bug reports for GNU Guix]

Hi,

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.

bug#36786: Warn of AMD GPUs unusable with Guix System

[pelzflorian (Florian Pelz)]

pelzflorian (Florian Pelz) wrote on 26 Jul 2019 22:03
> I would rather see a more prominent link to the manual and h-node
>  where on the downloads page it says “runs on i686, x86_64, ARM”,
>  because I suppose many people do not read the manual until they know
>  they need to, and instead expect things to just work, especially now
>  that there’s a graphical installer.

Closing.  Documenting non-working hardware is no longer necessary since
warnings were prominently added within the installer, as discussed at
.

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

[bbb ee]

In the documentation, when it says "guix search" search matching package,
if users don't find a package defined in .scm (hidden or no), users can
consider it is a bug, because that doesn't match the behavior described in
the specification (here, the manual and "guix search --help").

Le mar. 15 nov. 2022 à 15:54, zimoun  a écrit :

> Hi,
>
> On Tue, 15 Nov 2022 at 00:53, bbb ee  wrote:
>
> > in commit c81457, how gcc-toolchain can depends a package who doesn't
> > exists?
>
> The package exists, it is ’hidden’ – it means not accessible at the CLI
> level.  The ’inherit’ copies, so gcc-11 is also hidden, for instance.
>
> --8<---cut here---start->8---
> (define-public gcc-4.7
> [...]
> (hidden-package
>  (package
>(name "gcc")
>(version "4.7.4")
>
> (define-public gcc-4.8
>   (package (inherit gcc-4.7)
> (version "4.8.5")
>
> [...]
>
> (define-public gcc-11
>   (package
>(inherit gcc-8)
>(version "11.3.0")
> --8<---cut here---end--->8---
>
> The package ’gcc’ by itself is not barely useful because you also need
> linker etc. Well, you usually need a complete toolchain, named
> gcc-toolchain. ;-)
>
> See manual: <
> https://guix.gnu.org/manual/devel/en/guix.html#The-GCC-toolchain>
>
>
> So this is not a bug and I miss how what could be improved.  Closing?
>
> Cheers,
> simon
>

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

[bbb ee]

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:

in `guix search --help`, the documentation could be "Search for no hidden
packages matching REGEXPS."

in
https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html#Invoking-guix-package,
in the specification of the option -s :
"-s regexp

List the available packages whose name, synopsis, or description matches
regexp
"
What exactly means  "available" ?  For example, available means no hidden
guix package.

And in

Le mar. 15 nov. 2022 à 15:54, zimoun  a écrit :

> Hi,
>
> On Tue, 15 Nov 2022 at 00:53, bbb ee  wrote:
>
> > in commit c81457, how gcc-toolchain can depends a package who doesn't
> > exists?
>
> The package exists, it is ’hidden’ – it means not accessible at the CLI
> level.  The ’inherit’ copies, so gcc-11 is also hidden, for instance.
>
> --8<---cut here---start->8---
> (define-public gcc-4.7
> [...]
> (hidden-package
>  (package
>(name "gcc")
>(version "4.7.4")
>
> (define-public gcc-4.8
>   (package (inherit gcc-4.7)
> (version "4.8.5")
>
> [...]
>
> (define-public gcc-11
>   (package
>(inherit gcc-8)
>(version "11.3.0")
> --8<---cut here---end--->8---
>
> The package ’gcc’ by itself is not barely useful because you also need
> linker etc. Well, you usually need a complete toolchain, named
> gcc-toolchain. ;-)
>
> See manual: <
> https://guix.gnu.org/manual/devel/en/guix.html#The-GCC-toolchain>
>
>
> So this is not a bug and I miss how what could be improved.  Closing?
>
> Cheers,
> simon
>

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

[Sébastien FARGE]

Does a documentation with broken links makes sense ?I don't have the answer...envoyé : 15 novembre 2022 à 15:45de : zimoun à : Sébastien FARGE , 59...@debbugs.gnu.orgobjet : Re: bug#59277: Latest guix documentation - version number scrambled ?Hi,On lun., 14 nov. 2022 at 11:36, Sébastien FARGE  wrote:On the front page (https://guix.gnu.org/en/manual/devel/fr/) theversion number is replaced by a strange number 'e26b529'.This is the commit against which the documentation had been built.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-StickIndeed, but the image is not built for each commit. Well, I do not knowif it is fixable – or if it makes sense to fix. It is the devel manualafter all. ;-)i failed to download the iso image named : https://ftp.gnu.org/gnu/guix/guix-system-install-e26b529.x86_64-linux.iso’Specifically, the images are updated for each release, only.For the latest images, please see: https://guix.gnu.org/en/download/latest/Cheers,simon

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

[zimoun]

Hi,

On lun., 14 nov. 2022 at 11:36, Sébastien FARGE  
wrote:

> On the front page (https://guix.gnu.org/en/manual/devel/fr/) the
> version number is replaced by a strange number  'e26b529'.

This is the commit against which the documentation had been built.


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


> i failed to download the iso image named : 
> https://ftp.gnu.org/gnu/guix/guix-system-install-e26b529.x86_64-linux.iso’

Specifically, the images are updated for each release, only.

For the latest images, please see:

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


Cheers,
simon

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

[zimoun]

Hi,

On Tue, 15 Nov 2022 at 00:53, bbb ee  wrote:

> in commit c81457, how gcc-toolchain can depends a package who doesn't
> exists?

The package exists, it is ’hidden’ – it means not accessible at the CLI
level.  The ’inherit’ copies, so gcc-11 is also hidden, for instance.

--8<---cut here---start->8---
(define-public gcc-4.7
[...]
(hidden-package
 (package
   (name "gcc")
   (version "4.7.4")

(define-public gcc-4.8
  (package (inherit gcc-4.7)
(version "4.8.5")

[...]

(define-public gcc-11
  (package
   (inherit gcc-8)
   (version "11.3.0")
--8<---cut here---end--->8---

The package ’gcc’ by itself is not barely useful because you also need
linker etc. Well, you usually need a complete toolchain, named
gcc-toolchain. ;-)

See manual: 


So this is not a bug and I miss how what could be improved.  Closing?

Cheers,
simon

bug#59279: MPV does not work on X11 on Debian

[Jorge P. de Morais Neto]

Hi.  MPV stopped working on my Debian bullseye since the upgrade to
version 0.35.  I have locally fixed the problem by adding libxpresent
input to mpv recipe.

Regards
-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- Please adopt free/libre formats like PDF, Org, LaTeX, ODF, Opus, WebM and 7z.
- Libre apps for AOSP (Replicant, LineageOS, etc.) and Android: F-Droid
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"

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

[Sébastien FARGE]

Hello guix team,Looks like there is a bug in latest online guix documentation.On the front page (https://guix.gnu.org/en/manual/devel/fr/) the version number is replaced by a strange number  'e26b529'.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-Sticki failed to download the iso image named : https://ftp.gnu.org/gnu/guix/guix-system-install-e26b529.x86_64-linux.iso’I also noticed that this number change from day to day.Thanks.

bug#59200: ASDF build system/sbcl doesn't build FASLs on some packages

[Guillaume Le Vaillant]

Hi,

I can't reproduce this issue.

I tried
--8<---cut here---start->8---
guix shell sbcl sbcl-uuid --pure -- sbcl --eval '(require :asdf)' --eval 
'(asdf:load-system :uuid)'
guix shell sbcl sbcl-cl-containers --pure -- sbcl --eval '(require :asdf)' 
--eval '(asdf:load-system :cl-containers)'
--8<---cut here---end--->8---
and both commands worked without any error.

With each of the following commands, do you see the "uuid.fasl" file at
the end or not?
--8<---cut here---start->8---
ls -l $(guix build sbcl-uuid)/lib/common-lisp/sbcl/uuid/
ls -l $(guix build --check --no-grafts sbcl-uuid)/lib/common-lisp/sbcl/uuid/
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#59278:

[bbb ee]

close #59278

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

[bbb ee]

Thanks, I close the issue

Le mar. 15 nov. 2022 à 07:27, Julien Lepiller  a écrit :

> Hi,
>
> This is not a bug. The gcc package exists, but is hidden from CLI on
> purpose because you shouldn't install it and use it directly. You should
> use gcc-toolchain instead.
>
> Le 15 novembre 2022 00:53:32 GMT+01:00, bbb ee  a
> écrit :
>>
>> in version c81457a5883ea43950eb2ecdcbb58a5b144bcd11 of guix,
>> gcc-toolchain depends gcc:
>> ```
>> $ DEFAULT_CHANNELS=/tmp/default_channels.scm
>> $ echo "%default-channels" > $DEFAULT_CHANNELS
>> # I force guix to use only %default-channels here
>> $ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11  -C
>> $DEFAULT_CHANNELS -- search gcc-toolchain
>> guile: warning: failed to install locale
>> name: gcc-toolchain
>> version: 9.3.0
>> outputs: out debug static
>> systems: x86_64-linux i686-linux
>> dependencies: binutils@2.32 gcc@9.3.0 glibc@2.29 ld-wrapper@0
>> ```
>>
>>
>> However, I can't find gcc package in this version of guix
>> ```
>> $ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11  -C
>> $DEFAULT_CHANNELS -- search gcc
>> # no found gcc
>>
>> # guix install failure message confirm that gcc doesn't exist in commit
>> c81457
>> $ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11 -C
>> $DEFAULT_CHANNELS -- install gcc -p ~/opt/python-dev_3_7
>> guile: warning: failed to install locale
>> guix install: error: gcc: unknown package
>> ```
>>
>> in commit c81457, how gcc-toolchain can depends a package who doesn't
>> exists?
>>
>