Re: Packaging Proton Bridge: cryptic compilation failure

[sebastien]

Le samedi 30 novembre 2024 à 8:22 PM, Ian Eure  a écrit :

> 

> 

> Hi Marek,
> 

> On Sat, Nov 30, 2024, at 6:56 PM, Marek Paśnikowski wrote:
> 

> > On sobota, 30 listopada 2024 19:08:49 CET Cayetano Santos wrote:
> > 

> > > > sam. 30 nov. 2024 at 17:26, Marek Paśnikowski ma...@marekpasnikowski.pl
> > > > wrote:
> > > > Hello Guix
> > > > 

> > > > I am towards the end of a first pass of packaging the Proton Bridge
> > > > program to access my Proton Mail with KMail.
> > > > 

> > > > I have worked through and learned about many peculiarities of Golang 
> > > > build
> > > > system. As long as I had an error message, I was able to at least work
> > > > around problems. However, the latest build failure is completely cryptic
> > > > to me, as its log contains zero error messages. It works fine until I
> > > > get a "build
> > > > failed" summary:
> > > > The debug for dummies manual advices using the "--keep-failed" flag when
> > > > you build packages. Using a shell container helps to understand this 
> > > > kind
> > > > of cryptic messages too.
> > > 

> > > --
> > > Cayetano Santos
> > 

> > Thank you Ian, Cayetano for swiftly reminding me to Read The Manual. I was 
> > so
> > tired with constant tweaking of package after package, that I forgot to go 
> > to
> > the basics.
> > 

> > I learned that I can source variables to emulate the build environment, in
> > which I issued the same command that go build system uses to build the
> > package. Here is the result, much cleaner with the interesting stuff right 
> > at
> > the end:
> > 

> > [...]
> > # github.com/ProtonMail/go-crypto/openpgp/packet
> > /tmp/guix-build-go-github-com-protonmail-go-proton-api-0.4.0.drv-0/src/
> > github.com/ProtonMail/go-crypto/openpgp/packet/packet_sequence.go:12:92:
> > undefined: errors.ErrMalformedMessage
> > /tmp/guix-build-go-github-com-protonmail-go-proton-api-0.4.0.drv-0/src/
> > github.com/ProtonMail/go-crypto/openpgp/packet/packet_sequence.go:13:16:
> > undefined: errors.ErrMalformedMessage
> > /tmp/guix-build-go-github-com-protonmail-go-proton-api-0.4.0.drv-0/src/
> > github.com/ProtonMail/go-crypto/openpgp/packet/packet_sequence.go:94:17:
> > undefined: errors.ErrMalformedMessage
> > /tmp/guix-build-go-github-com-protonmail-go-proton-api-0.4.0.drv-0/src/
> > github.com/ProtonMail/go-crypto/openpgp/packet/config_v5.go:6:2: undefined:
> > V5Disabled
> > /tmp/guix-build-go-github-com-protonmail-go-proton-api-0.4.0.drv-0/src/
> > github.com/ProtonMail/go-crypto/openpgp/packet/marker.go:27:33: undefined:
> > packetTypeMarker
> > /tmp/guix-build-go-github-com-protonmail-go-proton-api-0.4.0.drv-0/src/
> > github.com/ProtonMail/go-crypto/openpgp/packet/padding.go:20:33: undefined:
> > packetPadding
> > 

> > I remember faking a Proton’s fork with the upstream package because GitHub
> > failed to find it. It could be the one, or not. At least I have a thread to
> > follow now; and a new tool for deep inspection.
> 

> 

> It's been a while since I've worked in Go, but based on: 
> https://github.com/ProtonMail/go-crypto/blob/main/openpgp/packet/packet_sequence.go#L9
> 

> ...I suspect the go-crypto repository houses multiple Go packages, which all 
> need to be packaged individually in Guix. It looks like your Guix packages 
> aren't doing that, which may explain the error you're getting. This is just a 
> hunch, it's been a few years since I wrote Go, and I never dealt with 
> packaging beyond stuffing static binaries into Docker containers -- but it 
> feels at least close to the root of the issue to me.
> 

> -- Ian

Hi,

As a everyday user of ProtonMail/guix for work i'm also interested to help you 
on this task. Perhaps could you provide a chan that contain only the 
dependencies and manifest to build proton-bridge ? 


That help us to reproduce the build and try to package and push go package that 
miss.

Best regards,
SR

publickey - s.rey.coyrehourcq@proton.me - 0xC3237850.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Packaging Proton Bridge: Progress Report #2

[sebastien]

Hi Marek,

Thanks for your work Marek, i try to compile on my guix system, and that works 
(build & install) ! 


For others interested to try :

a) create a directory proton-bridge & cd into
b) clone sovereign.git with "git clone 
https://git.marekpasnikowski.pl/sovereign.git/"; 

c) create a .channel file with this content : 


(cons 

  (channel
  (name 'sovereign)
  (url "xxx/sovereign") ; => replace xxx by your pwd
  (branch "master"))
  %default-channels
)

d) Run "guix time-machine -C channels.scm -- build -v 3 proton-bridge --cores=1"
e) Replace xxx by derivation builded in d) : "guix time-machine -C channels.scm 
-- install /gnu/store/xxx"
f) Run Desktop-Bridge 


Best regards,
SR










Le mardi 10 décembre 2024 à 11:28 AM, Marek Paśnikowski 
 a écrit :

> 

> 

> I successfully built target bridge-nogui .
> 

> The last step required implementation of a 'make' phase in the go build
> process. I considered splitting out the go component into its own package, to
> be an input of a qt package, but was not able to do it correctly.
> Implementation of a go process in the gnu, or qt, build system is not even
> worth considering. Thus I settled on invocation of "make" with some flags to
> make it work in the go build system.
> 

> I also decided against any further optimization of the make invocation,
> because I am planning to implement all the build targets defined by upstream,
> if possible.
> 

> At this point, I need to rest a little. I will test the binary I built, see
> if it even works. After that I am going to rewrite the module in a single
> style. Only then I will work on the other targets.
> 

> I also need to properly learn the peculiarities of the Go build system. I
> would not be able to go this far without using random elements found in other
> Go packages. It is unfortunate, that the build system reference page is
> missing some key concepts in the Go process.
> https://guix.gnu.org/manual/en/html_node/Build-Systems.html
> 

> Marek Pasnikowski
> 

> 

> 


publickey - s.rey.coyrehourcq@proton.me - 0xC3237850.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Gnome "oh no something has gone wrong..."

[sebastien]

Hi Christophe,

Actually i have the same problem after update guix pull & guix reconfigure to 
the last gnome version. 


Looking to /var/log/message in real time using tail -f /var/log/messages, i 
found there is an ugly segfault after more or less 1 minute in one of gds 
service 
(/gnu/store/qmjsxby7knqmy4h0rr9ahjm6713f150n-gnome-settings-daemon-47.2/libexec/gsd-usb-protection)
 launched by gnome at startup : gsd-usb-protection .gsd-ubs-protect , 
org.gnome.settingsDaemon.USBProtection.desktop ... This service is not 
accessible from dconf editor of gsettings

I found that it's possible to desactivate this gsd-usbprotector gnome service 
by modifying the corresponding gnome.session file : 


RequiredComponents=org.gnome.Shell;org.gnome.SettingsDaemon.A11ySettings;org.gnome.SettingsDaemon.Color;org.gnome.SettingsDaemon.Datetime;org.gnome.SettingsDaemon.Housekeeping;org.gnome.SettingsDaemon.Keyboard;org.gnome.SettingsDaemon.MediaKeys;org.gnome.SettingsDaemon.Power;org.gnome.SettingsDaemon.PrintNotifications;org.gnome.SettingsDaemon.Rfkill;org.gnome.SettingsDaemon.ScreensaverProxy;org.gnome.SettingsDaemon.Sharing;org.gnome.SettingsDaemon.Smartcard;org.gnome.SettingsDaemon.Sound;org.gnome.SettingsDaemon.UsbProtection;org.gnome.SettingsDaemon.Wacom;org.gnome.SettingsDaemon.XSettings;


BUT ... this is a readonly file in /gnu/store, so i'm actually blocked. I don't 
know how to modify this file to remove org.gnome.SettingsDaemon.UsbProtection

I guix rollback to go back to the previous working gnome version :(

Best regards,
Src.

Le samedi 15 mars 2025 à 2:50 PM, Luis Felipe  a écrit :

> 

> 

> Hi Christophe,
> 

> On 15/03/25 10:01, Christophe Pisteur wrote:
> 

> > Le vendredi 14 mars 2025 à 13:18 +, Luis Felipe a écrit :
> > 

> > > On 14/03/25 12:12, Christophe Pisteur wrote:
> > > 

> > > > I'll create a test user to see if it works for me too.
> > > > 

> > > > (...)
> > > 

> > > Please let us know how it goes,
> > 

> > I've created a new user according to your instructions and the result
> > is that the new user doesn't see an “oh no something has gone
> > wrong...” error message.
> > 

> > What should I do now?
> > How can I find out what's causing this malfunction in my user space,
> > given that I've already deleted ~/.config/dconf and
> > ~/.local/share/gnome-shell without solving the problem?
> 

> 

> In https://issues.guix.gnu.org/36924, they mention looking at
> ~/.cache/gdm/session.log. Mine lists several errors, even though my
> desktop is working normally, apparently. The same issue also mentions
> removing «.local/share» and «.cache». Personally, I'd remove the whole
> «.cache» directory, but I'd be more selective with «.local/share»,
> removing only things related to GNOME. So finding the root cause of the
> problem might feel like playing «pin the tail on the donkey».
> 

> If this is taking precious time from you, though, I'd recommend booting
> the previous generation of the system to see if it works correctly and
> use that  instead. You can select a previous generation from the GRUB
> menu when booting the system.
> 

> Hope that helps, good luck.

publickey - s.rey.coyrehourcq@proton.me - 0xC3237850.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Guix home, guix system, channels, some noob questions

[sebastien rey-coyrehourcq]

Hi,

I jump into guile world by learning and copy/pasting Dominic Martinez config :) 

Everything going pretty well but now i'm blocked with yubikey configuration. 

And without yubikey that contain your only private key to sign/decrypt 
everything, that's a little complicated ...

Running "gpg --card-status" my yubikey is correclty detected. That a good news 
... BUT that's all, 
other command don't work, for example both : 

gpg --list-secret-keys

gpg --list-keys 

don't ask pin, and return nothing when yubikey is plugged ... 
gnome seahorse also see nothing ...
emacs see anything when i try to decipher thing ...

I reboot and retry without success ...

I miss something with this $# gpg-agent conf ? 

I post the home config here : 

https://gitlab.com/reyman64/dotfiles

June 1, 2022 10:38:09 PM CEST "Sébastien Rey-Coyrehourcq" 
 wrote:Thanks Julien, Daniel, Dominic, 
Efraim for these very detailed answers 
and snippets, that will be very useful in my current migration from 
Ubuntu to Guix.

I answer here if i need some highlights or if i found interesting 
questions or remarks to share with you.

Best regards,

Le 26/05/2022 à 02:31, Dominic Martinez a écrit :
>
> Sébastien Rey-Coyrehourcq  
> writes:
>
>> The only things holding me back at the moment is two things :
>>
>> a) doom emacs flavour, how to manage the fact that doom use straigt.el
>> to maintain packages
>
> I don't think it's possible to use Doom with Guix emacs packages, but 
> you can just set up Doom as you would on another distro. I did this 
> while I transitioned to a Guix config, using ~home-files-service-type~ 
> to deploy my Doom config files.
>
>> b) "password / secrets" management ?
>>
>> There are two things, file to directly encrypt (like ssh key) and
>> password to hide into configuration file (templating)
>>
>> b.1) So, that need to encrypt/decrypt more or less "on-the-fly" the
>> files using gpg/yubikey or age like yadm ( 
>> https://yadm.io/docs/encryption ) or chezmoi
>> (https://www.chezmoi.io/user-guide/encryption/gpg/) do ?
>
> I use small wrappers around GPG's built in encryption 
> (https://git.sr.ht/~dominicm/dotfiles/tree/main/item/System.org#L2663) 
> and decryption 
> (https://git.sr.ht/~dominicm/dotfiles/tree/main/item/System.org#L2691) 
> functions to manage secrets directly in my repository on the fly. Then 
> I can have supported services call the script to get secrets without 
> storing them in plain-text 
> (https://git.sr.ht/~dominicm/dotfiles/tree/main/item/System.org#L1648).
>
>> b.2) And for templating, like replacing ${mypassword} into some
>> configuration file by getting info stored into password manager like 
>> "pass", i also don't know how to do that.
>
> Org makes this really convienent. Using noweb and shell scripts I can 
> decrypt and insert secrets into templated areas when I tangle my 
> configuration files. That way my repo only contains encrypted secrets, 
> but as long as I have my GPG keys I can build my configuration files 
> locally. See 
> https://git.sr.ht/~dominicm/dotfiles/tree/main/item/System.org#L5 and 
> https://git.sr.ht/~dominicm/dotfiles/tree/main/item/System.org#L1937.
>
>> c) synchronization of my .dotfiles between two different OS/System :
>> Ubuntu (home) / Guix (work & home)
>
> I keep all my configuration in a git repository, then use ~guix home~ 
> to put all the files in the right places. As others have noted, there 
> are many ways to identify the current system and do system-specific 
> operations. I personally use an environment variable to keep track, 
> and wrap guix operations with scripts that detect the system and use 
> different system/home configurations 
> (https://git.sr.ht/~dominicm/dotfiles/tree/main/item/System.org#L2366). 
> Then all I have to do is supply the script with the system name on the 
> first run, and ~home-environment-variables-service-type~ takes it from 
> there.

Lost all my guix home application packages from channels after guix update (pull, reconfigure)

[Sebastien Rey-Coyrehourcq]

Hi guix people,

I used guix home without problem last month but with a recent guix pull, guix 
system reconfigure, guix home reconfigure, all my package defined into guix 
home manifest disapear !!
And guix home say nothing (no error) about that. The only thing i change is 
removing zshrc to move on fish-service-type.

Here my configuration :

- $myconfigfolder/base/home.scm : https://paste.debian.net/1256154
- $myconfigfolder/base/package.scm : https://paste.debian.net/1256155
- $myconfigfolder/base/system.scm : https://paste.debian.net/1256156/

- $myconfigfolder/machines/Sulayh-latitude-home : 
https://paste.debian.net/1256157/
- $myconfigfolder/machines/Sulayh-latitude-system : 
https://paste.debian.net/1256158

To update system i run from : $myconfigfolder

- guix home -L . reconfigure machines/Sulayh-latitude-home
- sudo guix system -L . reconfigure machines/Sulayh-latitude-system


My describe for home

Génération 95   06 oct. 2022 10:55:04   (actuelle)
  nom de fichier : /var/guix/profiles/per-user/reyman/guix-home-95-link
  nom de fichier canonique : /gnu/store/mfylyvf57bpqjbxqvmxf1mj16cc9f17x-home
  canaux :
guix:
  URL du dépôt : https://git.savannah.gnu.org/git/guix.git
  branche : master
  commit : 40a42c4348635f186553938015f7e6a06be1e10c
guix-android:
  URL du dépôt : https://framagit.org/tyreunom/guix-android.git
  branche : master
  commit : 1e149a2cdbd221c299c9105e316f36717f81b41e
guix-science:
  URL du dépôt : https://github.com/guix-science/guix-science.git
  branche : master
  commit : 0ee692ecbc32f1917be3512953ee39762e7410c2
flat:
  URL du dépôt : https://github.com/flatwhatson/guix-channel.git
  branche : master
  commit : e57424b680e1724105e2598b68c30084b180cf58
my-guix:
  URL du dépôt : https://git.sr.ht/~reyman/channel-g/
  branche : master
  commit : 85cc8aa8c301eda46147f9e62989a0a1ff85a6e7
nonguix:
  URL du dépôt : https://gitlab.com/nonguix/nonguix
  branche : master
  commit : d7791ba66b806c54fbb16b531a79fe1793a61e35
  fichier de configuration : 
/gnu/store/vqb24jsz04kq9v5ldfbxjwh3744ak140-configuration.scm

My describe for system

Génération 65   06 oct. 2022 10:02:30   (actuelle)
  nom de fichier : /var/guix/profiles/system-65-link
  nom de fichier canonique : /gnu/store/5hrlb2wkznyhm2h2y7n0z0ypydacizqb-system
  étiquette : GNU with Linux 5.19.11
  chargeur de démarrage : grub-efi
  périphérique racine : /dev/mapper/cryptroot
  noyau : /gnu/store/sf67y13f80gcpa9dal9q96h86788nnmh-linux-5.19.11/bzImage
  canaux :
guix:
  URL du dépôt : https://git.savannah.gnu.org/git/guix.git
  branche : master
  commit : 40a42c4348635f186553938015f7e6a06be1e10c
guix-android:
  URL du dépôt : https://framagit.org/tyreunom/guix-android.git
  branche : master
  commit : 1e149a2cdbd221c299c9105e316f36717f81b41e
guix-science:
  URL du dépôt : https://github.com/guix-science/guix-science.git
  branche : master
  commit : 0ee692ecbc32f1917be3512953ee39762e7410c2
flat:
  URL du dépôt : https://github.com/flatwhatson/guix-channel.git
  branche : master
  commit : e57424b680e1724105e2598b68c30084b180cf58
my-guix:
  URL du dépôt : https://git.sr.ht/~reyman/channel-g/
  branche : master
  commit : 85cc8aa8c301eda46147f9e62989a0a1ff85a6e7
nonguix:
  URL du dépôt : https://gitlab.com/nonguix/nonguix
  branche : master
  commit : d7791ba66b806c54fbb16b531a79fe1793a61e35
  fichier de configuration : 
/gnu/store/gz3wln2riwbq41i6wg4sl425hwafhvkh-configuration.scm

Any help appreciated because loosing all packages (emacs, etc.) is a big 
handicap to work ...

Thanks,

Best regards,
Sébastien RC.

Re: Help packaging R Quarto Cli

[Sebastien Rey-Coyrehourcq]

Le Lundi, Octobre 24, 2022 13:43 CEST, Sébastien Rey-Coyrehourcq 
 a écrit:

> Hi,
>
> I’m trying to package Quarto Cli ( <https://github.com/quarto-dev/quarto-cli> 
> ), used in combination with Pandoc to publish -reproducible- scientific 
> document : website, blog, etc.
>
> I first think this is a classic gnu build : ./configure && make && make 
> install BUT, there is a problem because the ./configure script bootstrap 
> “Deno” during the run of configure.sh.
>
> Because this download and compilation of Deno occur during ./configure.sh 
> running, guix cannot patch the  #!/bin/bash path, so ./configure failed. Deno 
> seems also not packaged into guix.
>
> Do you have an idea to resolve this ? Perhaps we could try all together to do 
> this.
>
> I’m starting with this quarto-cli.scm :
>
> ┌
> │ (use-modules
> │ (guix packages)
> │ (guix download)
> │ (guix build-system gnu)
> │ (guix licenses)
> │ )
> │
> │ (define-public quarto-cli
> │   (package
> │ (name "Quarto-CLI")
> │ (version "1.1.251")
> │ (source (origin
> │   (method url-fetch)
> │   (uri (string-append 
> "https://github.com/quarto-dev/quarto-cli/archive/refs/tags/v"version".tar.gz";))
> │   (sha256
> │(base32
> │ "1ycwrjndrrrciymnm3l0lhcd375fddkvjibvc0n084irg6z1lxn6"
> │ (build-system gnu-build-system)
> │ (synopsis "Quarto-cli")
> │ (description
> │  "Quarto-cli description")
> │ (home-page "https://github.com/quarto-dev/quarto-cli";)

> │ (license gpl3+)))
> │ quarto-cli
> │
> └
>
> To compile and fail :
> guix build -f quarto-cli.scm
>
> Best,
> Sebastien RC.

Deno contain lot of packages dependencies actually,
here i comment all packages not packaged in rust after a simple run of guix 
import ...

#+BEGIN_SRC scheme

(use-modules
(guix packages)
(guix build-system cargo)
(guix download)
(guix licenses)
(gnu packages rust)
(gnu packages crates-io)
)

(define-public rust-deno-1
  (package
(name "rust-deno")
(version "1.26.2")
(source (origin
  (method url-fetch)
  (uri (crate-uri "deno" version))
  (file-name (string-append name "-" version ".tar.gz"))
  (sha256
   (base32
"1yzvdkj8sq475kfbkms1lfysjddkfwcyqhp1ggalfbk4hqhbiz29"
(build-system cargo-build-system)
(arguments
 `(#:cargo-inputs (("rust-atty" ,rust-atty-0.2)
   ("rust-base64" ,rust-base64-0.13)
;   ("rust-cache-control" ,rust-cache-control-0.2)

("rust-chrono" ,rust-chrono-0.4)
;   ("rust-clap" ,rust-clap-3)
;   ("rust-clap-complete" ,rust-clap-complete-3)
;   ("rust-clap-complete-fig" ,rust-clap-complete-fig-3)
("rust-data-url" ,rust-data-url-0.1)
;   ("rust-deno-ast" ,rust-deno-ast-0.19)
;   ("rust-deno-broadcast-channel" 
,rust-deno-broadcast-channel-0.67)
;   ("rust-deno-cache" ,rust-deno-cache-0.5)
;   ("rust-deno-console" ,rust-deno-console-0.73)
;   ("rust-deno-core" ,rust-deno-core-0.155)
;   ("rust-deno-core" ,rust-deno-core-0.155)
;   ("rust-deno-crypto" ,rust-deno-crypto-0.87)
;   ("rust-deno-doc" ,rust-deno-doc-0.46)
;   ("rust-deno-emit" ,rust-deno-emit-0.9)
;   ("rust-deno-fetch" ,rust-deno-fetch-0.96)
;   ("rust-deno-graph" ,rust-deno-graph-0.34)
;   ("rust-deno-lint" ,rust-deno-lint-0.33)
;   ("rust-deno-net" ,rust-deno-net-0.65)
;   ("rust-deno-node" ,rust-deno-node-0.10)
;   ("rust-deno-runtime" ,rust-deno-runtime-0.81)
;   ("rust-deno-task-shell" ,rust-deno-task-shell-0.5)
;   ("rust-deno-url" ,rust-deno-url-0.73)
;   ("rust-deno-web" ,rust-deno-web-0.104)
;   ("rust-deno-webgpu" ,rust-deno-webgpu-0.74)
;   ("rust-deno-websocket" ,rust-deno-websocket-0.78)
;   ("rust-deno-webstorage" ,rust-deno-webstorage-0.68)
   ("rust-dissimilar" ,rust-dissimilar-1)

Re: Help packaging R Quarto Cli

[Sebastien Rey-Coyrehourcq]

Hi,

You're both right, seems there is a flag to skip binary downloading and 
compile the V8 lib.


From the githubpage (https://github.com/denoland/rusty_v8) : "V8 is 
very large and takes a long time to compile. Many users will prefer to 
use a prebuilt version of V8. We publish static libs for every version 
of rusty v8 on Github .


Binaries builds are turned on by default: |cargo build| will initiate a 
download from github to get the static lib. To disable this build using 
the |V8_FROM_SOURCE| environmental variable.


When making changes to rusty_v8 itself, it should be tested by build 
from source. The CI always builds from source"


So, my packaging friend :), what's the best way to push an "export 
V8_FROM_SOURCE=1" or something like that into my rust-deno.scm ?


Best,

SR

Le 15/11/2022 à 08:58, Efraim Flashner a écrit :

On Mon, Nov 14, 2022 at 11:30:47PM +0100, Sébastien Rey-Coyrehourcq wrote:

Hi,

After some day of packaging rust crate, i progress and deno start to compile … 
but after 1min i have this error when cargo start compiling *rust-v8-0.49* . 
Any rust + guix help appreciated.

I push the channel to reproduce the problem here :

The rust scm repo : git.sr.ht:~reyman/rust-channel
Channel info to put into *channels.scm* :
The *rust-deno.scm* file to build :
The command : guix time-machine -C channels.scm – build -f rust-deno.scm

And the rust error :

—

error: failed to run custom build command for `v8 v0.49.0`

Caused by:
   process didn’t exit successfully: 
`/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/v8-bbb68ec56db1d802/build-script-build`
 (exit status: 101)
   — stdout
   cargo:rerun-if-changed=.gn
   cargo:rerun-if-changed=BUILD.gn
   cargo:rerun-if-changed=src/binding.cc
   cargo:rerun-if-env-changed=CCACHE
   cargo:rerun-if-env-changed=CLANG_BASE_PATH
   cargo:rerun-if-env-changed=DENO_TRYBUILD
   cargo:rerun-if-env-changed=DOCS_RS
   cargo:rerun-if-env-changed=GN
   cargo:rerun-if-env-changed=GN_ARGS
   cargo:rerun-if-env-changed=HOST
   cargo:rerun-if-env-changed=NINJA
   cargo:rerun-if-env-changed=OUT_DIR
   cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
   cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
   cargo:rerun-if-env-changed=SCCACHE
   cargo:rerun-if-env-changed=V8_FORCE_DEBUG
   cargo:rerun-if-env-changed=V8_FROM_SOURCE
   cargo:rustc-link-lib=static=rusty_v8
   download lockfile: 
“/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/build/lib_download.fslock”
   static lib 
URL:
   
cargo:rustc-link-search=/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/target/release/gn_out/obj
   
Downloading
   Python downloader failed, trying with curl.

Looks like you need to patch rust-v8-0.49 to not try to download
librusty_v8_release... but instead you'll have to build it from source
and let it know where to find it.


   — stderr
   thread ’main’ panicked at ’called `Result::unwrap()` on an `Err` value: Os { 
code: 2, kind: NotFound, message: “No such file or directory” }’, 
/tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.gz/build.rs:405:10
   note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish…
error: build failed
error: in phase ’build’: uncaught exception:
%exception #<&invoke-error program: “cargo” arguments: (“build” “–release”) 
exit-status: 101 term-signal: #f stop-signal: #f>
phase `build’ failed after 105.5 seconds
command “cargo” “build” “–release” failed with status 101
builder for `/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ 
failed with exit code 1
la compilation de 
/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv a échoué
Vous trouverez le journal de compilation dans « 
/var/log/guix/drvs/g4/m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv.gz ».
guix build: erreur : build of 
`/gnu/store/g4m5c558l1q4g1kggzg2v9vkw352nnaj-rust-deno-1.25.2.drv’ failed

Managing python entry-points to discover plugin package with the new pyproject-build-system ?

[Sebastien Rey-Coyrehourcq]

Hi, For my lab i actually manage to package the latest version (existing 
package on guix are old) of python mkdocs static site generator with 
mkdocs-materials theme. Mkdocs use a yaml entry to call the theme (here 
mkdocs-material-theme) to use for the website generation. Both project use a 
pyproject.toml for pip installation. An example of mkdocs.yml that use the 
material theme : ```yamlsite_name: my site nametheme:  name: material``` The 
name entry run/use python entry-points 
(https://peps.python.org/pep-0621/#entry-points) to detect theme actually 
installed with pip in the same context. Entry-point is a common way to 
install/link package as plugin. Even if my homemade package mkdocs-material is 
well installed and contain the entry-point.txt into dist-info/entry_points.txt 
that doesn't work. By looking in the build system of python i found some 
information about that : I package mkdocs-material using the new 
pyproject-build-system 
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/pyproject-build-system.scm
  My problem is that management of entry-points seems not implemented, as line 
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/pyproject-build-system.scm#n61
 say. Is there a way to implement this outside of pyproject-build-system, only 
for this project ? Best regards,SR