bug#48796: Guix on Debian 11 - Cant run or find applications from Guix

[Maxim Cournoyer]

Hi,

bo0od  writes:

> Everything is explained well in the past posts but no fixation proposed.
>
> Saying need info while all the info there is just ridiculous, closing
> the bug is just a bug skip not fix which lead to either more comments
> here or duplicates tickets else where.
>
> Unless there is a policy saying guix for guix OS only not for any
> other OS then this ticket is still valid.

I understand getting your issue closed without an apparent resolution
can be frustrating, but please keep the discussion courteous; we're
volunteers trying to keep the mountain of reported issues current and in
check.

For your info, this was fixed if you use the
https://guix.gnu.org/install.sh script with commits
30810aff713149d53cb25f36ae6d721ec66385da and
7ff169d04f52b15393b33a97959e2cd6a5957e26.

-- 
Thanks,
Maxim

bug#25018: GC incorrectly removes the temporary root file of the calling process

[Maxim Cournoyer]

Hi Ludovic!

Ludovic Courtès  writes:

> Hi Maxim,
>
> (Stripping Cc:.)
>
> Ludovic Courtès  skribis:
>
>> Thank you!  (Your bug triage work is much appreciated!)  We could turn
>> the example here in a unit test; the only downside is that running the
>> GC in a test is expensive.
>
> Actually, there are tests that most likely relied on the previous
> behavior and are now failing in
> tests/{derivations,nar,publish,pypi,store}.scm.  We’ll have to look at
> each one to make sure they are indeed making the wrong assumption and to
> fix them.

Hmm, I hadn't seen that coming.

> What about reverting the change first so we can do that without
> pressure and come up with a self-contained patch?

Sounds reasonable, if we can't think of an immediate fix.

-- 
Thanks,
Maxim

bug#58497: opam import doesn't work with ocaml_intrinsics among others

[Csepp]

Julien Lepiller  writes:

> (beautify-description #f _)
>
> Seems to be the cause. Yet, there is a description. Maybe parsing ends a bit 
> too soon?

That might explain issue 58112 as well.  I have a workaround that gives
#f for description.

bug#58568: Error when install the latest developments image

[Csepp]

Zhongyou Li  writes:

> Hi Guix,
> I got an error when install the latest developments image on virtual box on 
> macOS on MacBook Air
> 2015.
> I think the installation failed because the script did not delete the 
> download directory when the
> download failed, causing the directory name conflict when redownloading.
> I'm not sure if I'm right, so the specific information is below.
> For specific error messages, see the picture.
>
> Here is my configuration when install time:
> Local Language: English
> Local location: United States
> Graphical install using a terminal based interface
> Timezone: Asia, Shanghai

Looks like a substitution error, might have something to do with Guix
related servers being blocked in China and Russia, or at least they were
blocked recently.

bug#58571: translations are incompletely pulled from weblate

[two--- via Bug reports for GNU Guix]

hi
in https://git.savannah.gnu.org/cgit/guix.git/tree/po/guix/uk.po i see kyrylo's 
translations are pulled there from weblate, but mine 
(https://translate.fedoraproject.org/changes/?project=guix=uk=two22) 
are not, these strings stay untranslated or erroneous.

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[Marius Bakke]

Marius Bakke  skriver:

> I have a hunch that this has to do with the grafting code affecting
> origins (with gexps?), but have not confirmed this.

I have now confirmed this with a small shell script:

#!/bin/sh

pkg=$1

ungrafted="$(guix build --no-grafts -d $pkg)"
grafted="$(guix build -d $pkg)"

if [ $grafted = $ungrafted ]; then
echo $pkg has no grafts
else
grep "$ungrafted" "$grafted"
fi

It works for 'python-patiencediff', but fails for 'python-patch-ng',
both of which have no dependencies other than Python; but one uses
url-fetch and the other git-fetch.


signature.asc
Description: PGP signature

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[Marius Bakke]

Hello,

Sorry for the indescriptive title, I'm not entirely sure what is going
wrong here.  The problem is that for some packages, 'guix build -d foo'
has a different input derivation than the one produced by
'guix build --no-grafts -d foo'.

As an example, as of commit 3d8c243efb615c7e642942433be1c7badf0ae65e,
'guix build -d telegram-desktop' produces:

  /gnu/store/q1gx5xaszlyyr0sx663c2qkx92cqbr4r-telegram-desktop-4.2.2.drv

If we open that graft derivation, we see that it depends on:

  /gnu/store/92bl6qmj5r0byc59fykvlfaqmw6ikvy8-telegram-desktop-4.2.2.drv

However:

  $ guix build -d --no-grafts telegram-desktop
  /gnu/store/4vbj4gblmwvl645z1q3aaxfhckjqi3kg-telegram-desktop-4.2.2.drv

As a result:

  $ guix build telegram-desktop
  /gnu/store/6k2rdbc2v6nqyj2g445dii8gkamnbs43-telegram-desktop-4.2.2
  $ guix build --no-grafts telegram-desktop
  The following derivations will be built:
/gnu/store/4vbj4gblmwvl645z1q3aaxfhckjqi3kg-telegram-desktop-4.2.2.drv
/gnu/store/n0rdkaf91ifyvsr81hxcdlb8hg8k6rgh-fcitx-qt5-1.2.6.drv

This was discovered because users reported[0] missing substitutes for
telegram-desktop despite it being built by Cuirass.  We can see that it
has built the --no-grafts derivation:

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

...which is not being requested by end-users.

I have a hunch that this has to do with the grafting code affecting
origins (with gexps?), but have not confirmed this.

"Trivial" grafted packages such as 'perl-xml-parser' do not exhibit this
problem.

[0] https://logs.guix.gnu.org/guix/2022-10-16.log#152428


signature.asc
Description: PGP signature

bug#58149: bug#58526: bug report upgrading Guix from 1.0.1 to 1.3

[Maxime Devos]

reopen 58149
merge 58149 58526
thanks

I tried merging 58149 with 58526 because they appear to be essentially 
the same issue (pre-lzip stuff).


As far as I can tell, no fix for that problem was provided, and it's 
still happening (see, e.g., 58526).  As such, I'm reopening.


Feel free to reclose if I missed something.

Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58251: Mesa missing patches for Vulkan shared libraries

[Kaelyn via Bug reports for GNU Guix]

I've just sent in https://issues.guix.gnu.org/58566 to update mesa on 
core-updates, and that patch includes a new phase to fix up the Vulkan layer 
manifests similar to how I'd done for vulkan-validationlayers in 
https://issues.guix.gnu.org/57297.

bug#58526: bug report upgrading Guix from 1.0.1 to 1.3

[Maxime Devos]

merge 58149 58526
thanks

On 16-10-2022 17:25, Timothée Flutre wrote:

Here is the attachement, sorry for forgetting it the first time.


The 'unsuppported compression scheme lzip' looks like a duplicate of 
https://issues.guix.gnu.org/58149, merging.


Le sam. 15 oct. 2022 à 13:55, zimoun > a écrit :

[...]


I recommend against top-posting -- the e-mail clients I know of support 
methods for easy navigation to the mail that was replied to, no need to 
duplicate that.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58526: bug report upgrading Guix from 1.0.1 to 1.3

[Timothée Flutre]

Here is the attachement, sorry for forgetting it the first time.



Thank you Maxime.

I would like to (1) upgrade the deamon, and then (2) use it to update all
packages. I hence started by reading the manual:
https://guix.gnu.org/manual/en/html_node/Upgrading-Guix.html
Because I am running on a foreign distro, I used the command "sudo -i guix
pull" as indicated.

Following your advice, I used today "guix pull", but I got the same message.



Thank you Simon. I copy-pasted your command but I have no file named
"/gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af".

Best,
Timothée


Le sam. 15 oct. 2022 à 13:55, zimoun  a écrit :

> Hi,
>
> On Fri, 14 Oct 2022 at 20:08, Timothée Flutre  wrote:
>
> > I have a computer with Ubuntu 22.04.1 LTS". Some time ago, I installed
> Guix
> > to try it out, which I finally did not for various reasons. But hearing
> the
> > talk of K. Hinsen last month convinced me of giving it another try.
>
> Cool!
>
>
> > I hence started by upgrading Guix, like this:
> > sudo -i guix pull >& output_guix_pull.txt
>
> Well, the guix-daemon is probably too old.  Maybe you need something
> like [1]:
>
>sudo -i guix package --bootstrap -r guix -i \
>  /gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af
>
> 1: 
>
>
> > The whole report is attached in the file "output_guix_pull.txt".
>
> Missing attachment.
>
>
> Cheers,
> simon
>
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   a86979b
substitute: 
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
substitute: 
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
Computing Guix derivation for 'x86_64-linux'...  
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
downloading from 
https://ci.guix.gnu.org/nar/lzip/by8nai45wdxsmvq75972732jk3wpg0al-curl-7.84.0-doc...
Backtrace:
   3 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2  2 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  1 (_ #(#(#)))
In guix/ui.scm:
  1747:12  0 (run-guix-command _ . _)

guix/ui.scm:1747:12: In procedure run-guix-command:
unsupported compression scheme lzip
Backtrace:
  13 (primitive-load 
"/gnu/store/9bbc9z7lgfawd6lsviylw35qm2fy7rfb-compute-guix-derivation")
In ice-9/eval.scm:
155:9 12 (_ _)
159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 10 (with-fluid* _ _ _)
152:2  9 (with-fluid* _ _ _)
In ./guix/store.scm:
  2165:24  8 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
   1993:8  7 (_ _)
In ./guix/gexp.scm:
   300:22  6 (_ _)
   1181:2  5 (_ _)
   1047:2  4 (_ _)
893:4  3 (_ _)
In ./guix/store.scm:
  2050:12  2 (_ #)
   1398:5  1 (map/accumulate-builds # 
# ?)
  1414:15  0 (_ # _ _)

./guix/store.scm:1414:15: Throw to key `srfi-34' with args `(#)'.
guix pull: error: You found a bug: the program 
'/gnu/store/9bbc9z7lgfawd6lsviylw35qm2fy7rfb-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"a86979b41a49a8fcdaa887970ba594dbba701226"; system: "x86_64-linux";
host version: "1.0.1"; pull-version: 1).
Please report the COMPLETE output above by email to .

bug#58147: FAAC considered nonfree by Debian and Parabola

[Liliana Marie Prikler]

Am Mittwoch, dem 28.09.2022 um 18:41 -0400 schrieb Mark H Weaver:
> Based on the file names, I very much doubt that this library works at
> all without the nonfree source files.  Therefore, we must remove the
> 'faac' package from Guix.
> 
>   Thanks,
>     Mark
Took me long enough, but I now removed it.

Cheers

bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

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

Hi Brendan,

Oh!  This is a fun one!

Brendan Tildesley 写道：
However what concerned me more is that when I look in the source 
code

it looks like this:

(sha256
    (base32 
"9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))



Notice how at the start its a '9', not a '1'?

[…]

Is there a bug with how guix is reading/writing sha256 hashes?


It's… not a bug.  It's the opposite, kind of, although maybe 
(probably) Guix could (should) reject clearly bogus input like 
this.


What's happening is this:

In what can be described only as a bizarre coincidence, sha256 
produces hashes that are 256 bits long.


Base32¹ encodes 5 bits per character.  Our ‘hash’ strings are 
currently 52 characters long, meaning they encode 260 bits.


If you poke around Guix, you'll notice that every valid base32 
‘sha256’ hash starts with a 0 or a 1, because those 4 leftmost 
bits are never used, and hence set to zero.


In the case of this "9…" ‘hash’ (which was random data, I guess?), 
Guix still reads only 256 bits of the 260, and ignores those 4 
‘extra’ leftmost bits.


When it later prints the hash, it converts those 256 bits back to 
base32, now padded with zeroes, and you see a ‘hash’ starting with 
1.


What Guix could do is refuse to continue when it detects set 
higher bits, as they always indicate programmer error.


Kind regards,

T G-R

1: Guix uses ‘nix-base32’ which uses a slightly different alphabet 
from the more common base32 variant, but is otherwise identical in 
operation.


signature.asc
Description: PGP signature

bug#58555: [guile-git] Attempt to use git repositories that support older "dumb" HTTP protocol gives uninformative error message

[Maxime Devos]

On 15-10-2022 17:08, Wojtek Kosior via Bug reports for GNU Guix wrote:

Hello,

I was trying to set up a Guix channel and use it from guix.scm of my
project. I got an error when using `guix shell`


Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Updating channel 'hydrilla-guix' from Git repository at 
'https://git.koszko.org/hydrilla-guix-packaging'...
SWH: revision "7ffa00d8923f518d4d3898d2b9f6673afe204660" originating from 
https://git.koszko.org/hydrilla-guix-packaging could not be found
guix shell: warning: revision 7ffa00d8923f518d4d3898d2b9f6673afe204660 of 
https://git.koszko.org/hydrilla-guix-packaging could not be fetched from 
Software Heritage
guix shell: error: failed to load 'guix.scm':
guix/git.scm:401:19: Git error: invalid content-type: 'text/plain; 
charset=UTF-8'


I investigated this and found out it's guile-git that fails to HTTP
clone repositories that use the older "dumb" git protocol instead of
the newer "smart" one.

> [...]

This is a limitation of the libgit2 library that is used by guile-git:
.
Currently there don't appear to be any plans upstream for supporting the 
'dumb' protocol.  If you would like support for the 'dumb' protocol, 
you'll need to contact libgit2, and probably write the patch yourself.



[...]
Nick's repo that I am using here only supports the dumb protocol. Hence
the following error


Backtrace:
In ice-9/boot-9.scm:
   1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
6 (apply-smob/0 #)
In ice-9/boot-9.scm:
 724:2  5 (call-with-prompt _ _ #)
In ice-9/eval.scm:
 619:8  4 (_ #(#(#)))
In ice-9/command-line.scm:
185:19  3 (_ #)
In unknown file:
2 (eval (clone "https://git.nicksphere.ch/calcurse; "/…") #)
In git/clone.scm:
  46:8  1 (_ _ _ _)
In git/bindings.scm:
  77:2  0 (raise-git-error _)

git/bindings.scm:77:2: In procedure raise-git-error:
Throw to key `git-error' with args `(#< code: -1 message: "invalid 
content-type: 'text/plain; charset=UTF-8'" class: 34>)'.


The expected behavior is that instead the user gets a meaningful
message, e.g. "Repository at  could not be used because it doesn't
support the newer \"smart\" git HTTP protocol. Please ask the
repository owner to add support for that protocol".

>

I didn't see any mailing list for guile-git and I noticed most recent
commits in guile-git are from Guix maintainer anyway so I decided to
just submit to Guix bug mailing list. I hope I'm not doing something
horribly wrong here :)


It uses GitLab's issue tracker.  I've added a link at 
.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58555: [guile-git] Attempt to use git repositories that support older "dumb" HTTP protocol gives uninformative error message

[Wojtek Kosior via Bug reports for GNU Guix]

Hello,

I was trying to set up a Guix channel and use it from guix.scm of my
project. I got an error when using `guix shell`

> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Updating channel 'hydrilla-guix' from Git repository at 
> 'https://git.koszko.org/hydrilla-guix-packaging'...
> SWH: revision "7ffa00d8923f518d4d3898d2b9f6673afe204660" originating from 
> https://git.koszko.org/hydrilla-guix-packaging could not be found
> guix shell: warning: revision 7ffa00d8923f518d4d3898d2b9f6673afe204660 of 
> https://git.koszko.org/hydrilla-guix-packaging could not be fetched from 
> Software Heritage
> guix shell: error: failed to load 'guix.scm':
> guix/git.scm:401:19: Git error: invalid content-type: 'text/plain; 
> charset=UTF-8'

I investigated this and found out it's guile-git that fails to HTTP
clone repositories that use the older "dumb" git protocol instead of
the newer "smart" one.

I have since added support for "smart" git protocol in my repository at
git.koszko.org. However, I found a way to reproduce this issue directly
in guile-git. I used more or less the following commands

cd /tmp/
git clone https://gitlab.com/guile-git/guile-git.git
cd guile-git; patch --strip 1 < 
~/.config/guix/current/share/guile/site/3.0/gnu/packages/patches/guile-git-adjust-for-libgit2-1.2.0.patch
guix shell -f guix.scm nss-certs guile libgit2 guile-bytestructures -- 
guile -c '(use-modules (git bindings) (git clone)) (libgit2-init!) (clone 
"https://git.nicksphere.ch/calcurse; "/tmp/gitclonetest")'

Nick's repo that I am using here only supports the dumb protocol. Hence
the following error

> Backtrace:
> In ice-9/boot-9.scm:
>   1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>6 (apply-smob/0 #)
> In ice-9/boot-9.scm:
> 724:2  5 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
> 619:8  4 (_ #(#(#)))
> In ice-9/command-line.scm:
>185:19  3 (_ #)
> In unknown file:
>2 (eval (clone "https://git.nicksphere.ch/calcurse; "/…") #)
> In git/clone.scm:
>  46:8  1 (_ _ _ _)
> In git/bindings.scm:
>  77:2  0 (raise-git-error _)
> 
> git/bindings.scm:77:2: In procedure raise-git-error:
> Throw to key `git-error' with args `(#< code: -1 message: "invalid 
> content-type: 'text/plain; charset=UTF-8'" class: 34>)'.

The expected behavior is that instead the user gets a meaningful
message, e.g. "Repository at  could not be used because it doesn't
support the newer \"smart\" git HTTP protocol. Please ask the
repository owner to add support for that protocol".

I didn't see any mailing list for guile-git and I noticed most recent
commits in guile-git are from Guix maintainer anyway so I decided to
just submit to Guix bug mailing list. I hope I'm not doing something
horribly wrong here :)

Best,
Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!   #35: blessed Józef Innocenty Guz
Poznaj świętych krakowskich!  #35: błogosławiony Józef Innocenty Guz
https://pl.wikipedia.org/wiki/Józef_Innocenty_Guz
-- (sig_end)


pgpmh8wIniGR6.pgp
Description: OpenPGP digital signature