Re: Building a Docker image for GitLab-CI
Hi, Efraim Flashner skribis: > In the past I used a script to install guix using the shell script and > then ran guix pull before building my package. I suppose you could use > a Debian image and run 'guix pull' first before building something. I could… but that’d be cheating. :-) Ludo’.
Re: Guix Days: Patch flow discussion
Hi Steve, ( On a side note, the triage of old bugs is a similar problem. They are easy to find [2], read, check and send an email to 12...@debbugs.gnu.org does not appear to me an issue with any tool. For what it is worth and without any willing of being harsh, I am able to count the people doing this boring task. What is hard to solve is the incentives for doing the boring, but necessary, collective tasks. Bah the usual problem of lengthy discussions with roommates in any shared apartment: who clean the bathroom? :-) ) On lun., 05 févr. 2024 at 09:39, Steve George wrote: > Our goal for the discussion: > > How do we double the number of patches that are *reviewed* and > *applied* to Guix in the next six months? Thanks for these notes and leading the session. On my side, it was a fruitful discussion. Well, let me try to quickly summarize my conclusion of the session: 1. We have a social/organisational problem. 2. We have some tooling annoyances. The easy first: #2 about tools. The email workflow is often cited as part of the issue. That’s a false-problem, IMHO. Projects that use PR/MR workflow have the same problem. For instance, Julia [1] has 896 open PR. On my browser, it means 36 pages so if I go to – 25 PRs per page – the still open submitted PRs: + the 6th page: around Sept.2023 and Oct. 2023 + the 12th page: around Apr. 2023 and Mar. 2023 + the 18th page: around Jul. 2022 and Mar. 2022 + the 24th page: around Jun. 2021 and May 2021 + the 30th page: around Mar. 2020 and Oct. 2019 + the 36th page: around Mar. 2017 and May. 2014 Obviously, an example is not a proof or an evidence. It is just a first clue. :-) I will not speak about the channel ’nonguix’ but it gives another clue. That said, for sure, the tools need more love. Thanks all the people for all hard work over the years in this area – no name, you know, I fear to forget someone. ;-) So, yeah we need to smooth the technical burden for reviewing in order to focus on the review itself. To be clear, the email workflow might add burden on submitter side but I am doubtful it is really part of the bottleneck for reviewing and pushing submissions. Although the tools might add some unnecessary friction, the net of the issue is IMHO #1: reviewing is just boring and time-consuming. Who feel accountable? And for what? That’s the question, IMHO. If the number of submission is doubled, how do we increase the number of people that feel enough accountable for doing the boring work? ( Maybe accountable is not the correct word. Obligation neither. Well the kind of feeling that is okish if you skip the task but you know it will be better if you do it. ) Well, the difficult part is not pressing some buttons for merging and pushing – whatever the tools or workflow. The difficult part is to scrutinize the submission. I think the bottleneck is not the number of people able to push. Instead, I think the bottleneck is the number of people confident with the change for then pushing it. The question is thus: how to build this confidence? Look, when a committer has some free-time, most of the time, what is the process: take first the “easy“ submissions for committing them – from trivial updates to simple updates. If free-time remains, then engage with more “complex” submissions… ah no more free-time. :-) Why starting by the “easy” submission? Because it is less boring and time-consuming; somehow it is easier to feel confident with that sort of change for pushing it. As a rule of thumb, about the time it takes – on average –, the order of magnitude for reviewing is similar as the one for submitting. Well, from my experience and although I never did stats. :-) All in all, I see two paths to move forward: i) Non-committers can help. On two fronts: + Answer to submitter with the changes for being compliant with Guix standards. + Follow-up on patches already commented but without an updated revision: upgrade the re-roll count by sending this revision. It eases for merging if I do not have to make many tiny edits myself. ii) Create more teams or at least more people should commit to be part of a team and help in reviewing what they know. For instance, since Sept. (167 days ago) I have been CC in 108 patches submissions. Most of them are from ’core’ team that I would qualify as “complex”. :-) Many patches assigned to ’core’ team are sent by committers. The issue is not being a committer or not. Instead, being more eyes commenting would increase the confidence. Thus it would reduce the workload. That’s the same for any team, IMHO. And I do not speak about patches that are not assigned to any team. Somehow, we need to think how people would feel “accountable” for doing the collective tasks with low, no direct or personal reward. As with many non-technical topic
How to debug a failed build of rust application under cargo-build-system?
Greetings,
I am trying to package a rust application and the build fails. I am not sure
how to debug that. When I try to compile the application using `cargo install',
it does pass and build just fine. However, when I try to build the application
(imported using the cargo importer) using `guix build', I get this error:
Compiling tonic v0.10.2
error[E0277]: the `?` operator can only be used in an async block that
returns `Result` or `Option` (or another type that implements `FromResidual`)
-->
/tmp/guix-build-netavark-1.10.3.drv-0/netavark-1.10.3/guix-vendor/rust-tonic-0.10.2.tar.gz/src/transport/server/incoming.rs:32:45
|
28 | / async_stream::try_stream! {
29 | | tokio::pin!(incoming);
30 | |
31 | | while let Some(item) = incoming.next().await {
32 | | yield item.map(ServerIo::new_io)?
| | ^ cannot use the `?`
operator in an async block that returns `()`
33 | | }
34 | | }
| |_- this function should return `Result` or `Option` to accept `?`
|
= help: the trait `FromResidual>` is
not implemented for `()`
For more information about this error, try `rustc --explain E0277`.
error: could not compile `tonic` (lib) due to previous error
I am not know rust, but this looks like a code error? If that is the case, I do
not understand why `cargo install' works, since it should be using the same
code.
Could someone nudge me in the right direction regarding how to debug this issue?
I am not really sure where to start.
Thank you and have a nice day,
Tomas Volf
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
Re: torbrowser
Hi Gottfried,
This is great! Thanks for letting me know.
Kind regards,
Clément
On Thu, Feb 15, 2024, at 11:36 AM, Gottfried wrote:
> Hi Clement,
>
> now after updating my manifest it worked:
> It downloaded torbrowser additional to icecat and ungoogled-chromium
>
>
> gfp@Tuxedo ~$ guix package -p /home/gfp/Projekte/Icecat/guix-profil -m
> /home/gfp/Projekte/Icecat/icecat.scm
> Die folgenden Pakete werden installiert:
> icecat 115.7.0-guix0-preview1
> torbrowser 13.0.9
> ungoogled-chromium 112.0.5615.165-1
>
> I am happy
> thanks for your help
>
> Kind regards
>
> Gottfried
>
>
> Am 18.01.24 um 15:57 schrieb Clément Lassieur:
> > No problem
> >
> > Maybe you are not in the good place
> >
> > can you show the output of:
> >
> > pwd
> >
> > ?
> >
> > Also, where is "gfp" located?
> >
> > On Thu, Jan 18, 2024, at 3:01 PM, Gottfried wrote:
> >> Am 18.01.24 um 15:39 schrieb Clément Lassieur:
> >> > so what is the file that contains
> >> >
> >> > ;; Icecat Manifest
> >> > (specifications->manifest '("icecat" "ungoogled-chromium"
> >> > "torbrowser"))
> >> >
> >>
> >> The file is :
> >>
> >> icecat.scm
> >>
> >> it is located unter:
> >>
> >> gfp/Projekte/Icecat/
> >>
> >>
> >> May be I don't understand something.
> >>
> >> Sorry for the inconvenience.
> >>
> >>
> >>
> >>
> >>
> >> >
> >> > On Thu, Jan 18, 2024, at 2:42 PM, Gottfried wrote:
> >> >> Am 18.01.24 um 15:20 schrieb Clément Lassieur:
> >> >> > does the file exist?
> >> >> >
> >> >> > What is the output of:
> >> >> >
> >> >> > cat gfp/Projekte/Icecat/icecat.scm
> >> >>
> >> >>
> >> >> gfp@Tuxedo ~$ cat gfp/Projekte/Icecat/icecat.scm
> >> >> cat: gfp/Projekte/Icecat/icecat.scm: No such file or directory
> >> >>
> >> >>
> >> >> >
> >> >> > And what is the output of:
> >> >> >
> >> >> > guix package -m gfp/Projekte/Icecat/icecat.scm
> >> >> >
> >> >>
> >> >>
> >> >> gfp@Tuxedo ~$ guix package -m gfp/Projekte/Icecat/icecat.scm
> >> >> guix package: error: failed to load 'gfp/Projekte/Icecat/icecat.scm':
> >> >> ice-9/boot-9.scm:2190:9: In procedure primitive-load-path: Unable to
> >> >> find file "guix/gfp/Projekte/Icecat/icecat.scm" in load path
> >> >>
> >> >> Kind regards
> >> >>
> >> >> Gottfried
> >> >>
> >> >>
> >> >> *Attachments:*
> >> >>
> >> >> * OpenPGP_0x61FAF349C9FB7F94.asc
> >> >> * OpenPGP_signature
> >> >
> >>
> >> --
> >> Kind regards
> >>
> >> Gottfried
> >>
> >>
> >>
> >> *Attachments:*
> >>
> >> * OpenPGP_0x61FAF349C9FB7F94.asc
> >> * OpenPGP_signature
> >
>
> --
>
>
> *Attachments:*
> • OpenPGP_0x61FAF349C9FB7F94.asc
> • OpenPGP_signature
Re: Help with channel build system and package
About the warnings of invalid argument list: comment out the argument lists in
the toolchain packages (I do not remember fully the names, I do not have acces
to the big computer right now for easy reference). See how the change effects
the build.
I learned a lot by intentionally breaking code and reading the errors.
I ended up trying that, removing the arguments from the package, but I
did not get any change in the output.
One thing I did try is trying to build with the repl. I made this
script, named build-repl.scm:
(use-modules
(guix store)
(guix derivations)
(guix packages)
;;(embedded-dev packages)
)
(define (build-packages packages)
(with-store store
(let ((builds (map (lambda (package)
(package-derivation store package))
packages)))
(build-derivations store builds
(define (build-package package)
(build-packages (list package)))
Which i got from here:
https://lists.gnu.org/archive/html/help-guix/2020-06/msg00173.html
I don't seem to be able to use my channel here for some reason but I
think I got around that later.
For context, this is my directory layout:
embedded-dev-chan
├── build-repl.scm
├── .guix-channel
└── embedded-dev
├── build
│ └── crosstool-ng-build-system.scm
├── build-system
│ └── crosstool-ng.scm
└── packages
└── crosstool-ng.scm
My understanding is that by adding embedded-dev-chan to the load path I
should be able to use the guile files inside with something like
(use-modules embedded-dev packages crosstool-ng).
I invoked the repl: guix repl -L /home/jesse/Code/embedded-dev-chan
Then I loaded the "build-repl.scm" script and tried to build my package:
scheme@(guix-user)> ,load /home/jesse/Code/embedded-dev-chan/build-repl.scm
scheme@(guix-user) [2]> (use-modules (embedded-dev packages crosstool-ng))
While compiling expression:
Syntax error:
unknown location: lambda*: invalid argument list in subform ((phases
(quote %standard-phases)) (outputs (quote ("out"))) (search-paths (quote
())) (system (%current-system)) (guile #f) (imported-modules
%crosstool-ng-build-system-modules) (modules (quote ((embedded-dev build
crosstool-ng-build-system) (guix build utils) of (name inputs
(phases (quote %standard-phases)) (outputs (quote ("out")))
(search-paths (quote ())) (system (%current-system)) (guile #f)
(imported-modules %crosstool-ng-build-system-modules) (modules (quote
((embedded-dev build crosstool-ng-build-system) (guix build utils)
This seems like it is giving me a little more to go off of. I pretified
the output a bit:
((phases
(quote %standard-phases))
(outputs (quote ("out")))
(search-paths (quote ()))
(system (%current-system))
(guile #f)
(imported-modules %crosstool-ng-build-system-modules)
(modules
(quote ((embedded-dev build crosstool-ng-build-system)
(guix build utils)
of
(name
inputs
(phases (quote %standard-phases))
(outputs (quote ("out")))
(search-paths (quote ()))
(system (%current-system))
(guile #f)
(imported-modules %crosstool-ng-build-system-modules)
(modules (quote ((embedded-dev build crosstool-ng-build-system)
(guix build utils)
I'm not quite sure what this is trying to tell me. It seems like it is
an issue around here in embedded-dev/build-system/crosstool-ng.scm:
(define* (crosstool-ng-build name inputs
(phases '%standard-phases)
(outputs '("out"))
(search-paths '())
(system (%current-system))
(guile #f)
(imported-modules
%crosstool-ng-build-system-modules)
(modules '((embedded-dev build
crosstool-ng-build-system)
(guix build utils)))
)
"Build Crosstool-ng toolchain"
(define build
#~(begin
(use-modules #$@(sexp->gexp modules))
#$(with-build-variables inputs outputs
#~(crosstool-ng-build #:name #$name
#:source #+source
#:system #$system
#:phases #$(if (pair? phases)
(sexp->gexp phases)
phases)
#:outputs %outputs
#:search-paths '#$(sexp->gexp
(map
search-path-specification->sexp
search-paths))
#:inputs %build-inputs
(mlet %store-monad ((guile (package->derivation (or guile
(default-guile))
system #:graft? #f)))
(gexp->derivation name build
#:system system
#:target #f
#:modules import
Re: How to debug a failed build of rust application under cargo-build-system?
On 2024-02-15 13:06:23 +, woshilapin wrote:
> Hi,
>
> It is indeed a code error which looks weird. Are you sure the 2 compilations
> compile the same source code?
Well, technically I am not sure. I ran the `guix import crate -r netavark' and
used the output from that. My expectation was that it would walk the
dependencies, and produce the same dependency tree cargo would use. Is that a
correct expectation?
> How do you invoke `cargo install`?
cargo install netavark
Which seems to install 1.10.3 version. That does match my package:
(name "netavark")
(version "1.10.3")
(source
(origin
(method url-fetch)
(uri (crate-uri "netavark" version))
(file-name (string-append name "-" version ".tar.gz"))
(sha256
(base32 "1viyj9xqq9hkcsghrfx7wjmky3hkxfr96952f9favd4zg9ih64yw"
(build-system cargo-build-system)
When I check the failing tonic crate, both (guix package and in output for the
cargo install above) are in 0.10.2 version.
> Because if you invoke `cargo install --path .`, then I'm pretty sure it's
> compiling whatever is on your machine at the current directory. However, any
> other invocation of `cargo install` might actually pull some source from
> `crates.io` (the package registry for `cargo`). For example, `cargo install
> cargo-nextest` will download.
> Same applies for `guix build` (I'm a guix very beginner so I might not be the
> best at this), I'm not sure `guix build` build the current directory. Doesn't
> it build the `package.scm` which itself describe where to pull the source
> code?
>
> So, trying a way to be sure that `cargo install` and `guix build` actually
> build the same source code might a first step. I hope this helps.
>
> Have a nice day.
> --
> woshilapin
>
> Le jeudi 15 février 2024 à 13:43, Tomas Volf <~@wolfsden.cz> a écrit :
>
> > Greetings,
> >
> > I am trying to package a rust application and the build fails. I am not sure
> > how to debug that. When I try to compile the application using `cargo
> > install', it does pass and build just fine. However, when I try to build
> > the application (imported using the cargo importer) using` guix build', I
> > get this error:
> >
> > Compiling tonic v0.10.2
> > error[E0277]: the `?` operator can only be used in an async block that
> > returns `Result` or `Option` (or another type that implements
> > `FromResidual`)
> > -->
> > /tmp/guix-build-netavark-1.10.3.drv-0/netavark-1.10.3/guix-vendor/rust-tonic-0.10.2.tar.gz/src/transport/server/incoming.rs:32:45
> >
> > |
> > 28 | / async_stream::try_stream! {
> > 29 | | tokio::pin!(incoming);
> > 30 | |
> > 31 | | while let Some(item) = incoming.next().await {
> > 32 | | yield item.map(ServerIo::new_io)?
> > | | ^ cannot use the `?` operator in an async block that returns `()`
> > 33 | | }
> > 34 | | }
> > | |_- this function should return `Result` or `Option` to accept `?`
> > |
> > = help: the trait `FromResidual>` is
> > not implemented for `()`
> >
> >
> > For more information about this error, try `rustc --explain E0277`.
> > error: could not compile `tonic` (lib) due to previous error
> >
> > I am not know rust, but this looks like a code error? If that is the case,
> > I do
> > not understand why `cargo install' works, since it should be using the same
> > code.
> >
> > Could someone nudge me in the right direction regarding how to debug this
> > issue?
> > I am not really sure where to start.
> >
> > Thank you and have a nice day,
> > Tomas Volf
> >
> > --
> > There are only two hard things in Computer Science:
> > cache invalidation, naming things and off-by-one errors.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
Re: How to debug a failed build of rust application under cargo-build-system?
> Tomas Volf <~@wolfsden.cz> hat am 15.02.2024 14:26 CET geschrieben: > > > On 2024-02-15 13:06:23 +, woshilapin wrote: > > Hi, > > > > It is indeed a code error which looks weird. Are you sure the 2 > > compilations compile the same source code? > > Well, technically I am not sure. I ran the `guix import crate -r netavark' > and > used the output from that. My expectation was that it would walk the > dependencies, and produce the same dependency tree cargo would use. Is that a > correct expectation? Not necessarily correct, no. cargo install does not use the lockfile, see https://doc.rust-lang.org/cargo/commands/cargo-install.html#dealing-with-the-lockfile The cargo-build-system also doesn't use it. The crate importer also doesn't use it :) > > > Could someone nudge me in the right direction regarding how to debug this > > > issue? > > > I am not really sure where to start. First, I'd try to make sure that guix build rust-tonic works. This page helped me a lot in getting started: https://guix.gnu.org/manual/en/html_node/Debugging-Build-Failures.html I tried to reproduce this locally (import and build), building rust-tonic works fine for me. Funnily enough, I'm running into a completely different error, related to https://github.com/hyperium/tonic/blob/408f46d5f2e1a25547831eb4b064bdeaf3868979/tonic-build/src/lib.rs#L47-L60
Re: How to debug a failed build of rust application under cargo-build-system?
On 2024-02-15 15:42:51 +0100, Nils Landt wrote: > > Tomas Volf <~@wolfsden.cz> hat am 15.02.2024 14:26 CET geschrieben: > > > > > > On 2024-02-15 13:06:23 +, woshilapin wrote: > > > Hi, > > > > > > It is indeed a code error which looks weird. Are you sure the 2 > > > compilations compile the same source code? > > > > Well, technically I am not sure. I ran the `guix import crate -r netavark' > > and > > used the output from that. My expectation was that it would walk the > > dependencies, and produce the same dependency tree cargo would use. Is > > that a > > correct expectation? > > Not necessarily correct, no. > cargo install does not use the lockfile, see > https://doc.rust-lang.org/cargo/commands/cargo-install.html#dealing-with-the-lockfile > The cargo-build-system also doesn't use it. > The crate importer also doesn't use it :) Oh... Right, so I managed to track down the difference. The importer uses async-stream in 0.3.2 while cargo in 0.3.5. After updating the packaged version to 0.3.5, it now compiles, so that is nice. Wait, it is not. I assumed that rust is big on the semver. Should 0.3.2 and 0.3.5 be the same (except bug fixes)? :-O > > > > > Could someone nudge me in the right direction regarding how to debug > > > > this issue? > > > > I am not really sure where to start. > > First, I'd try to make sure that guix build rust-tonic works. > > This page helped me a lot in getting started: > https://guix.gnu.org/manual/en/html_node/Debugging-Build-Failures.html > > I tried to reproduce this locally (import and build), building rust-tonic > works fine for me. > Funnily enough, I'm running into a completely different error, related to > https://github.com/hyperium/tonic/blob/408f46d5f2e1a25547831eb4b064bdeaf3868979/tonic-build/src/lib.rs#L47-L60 > Yep, you need to provide PROTOC environment variable or patch the source code (what I do). But thanks to you I managed to solve this, so thanks :) Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: guix on nfs based systems
Hi Étienne, I am very late to the party. :-) Well, there is a discussion about “guix shell”, “profile” and “guix time-machine”. Since these concepts can appear as first as alien, let me try a quick summary of my understanding. + “guix shell“ creates a temporary profile; + “guix time-machine” creates a temporary revision. For the plumbing details, both live under “~/.cache/guix/” and all is managed automatically. An example: $ guix package -m manifest.smc -p /tmp/foo $ GUIX_PROFILE="/tmp/foo" $ . "$GUIX_PROFILE/etc/profile" Instead, $ guix shell -m manifest.scm somehow does the same but the user does not manually manage the profile and activate it. This profile is automatically and transparently managed. Now, you might run “guix pull”, so there is a chance that the next “guix shell” will not build the same underlying profile. That’s where “guix time-machine” comes in. :-) You “freeze” one revision with “guix describe -f channels > channels.scm” then run guix time-machine -C channels.scm -- shell manifest.scm It is costly the first run, then all is cached. Somehow, this command could be seen as “conda env activate“ coupled to some lock stuff. All that said, one thing to know: when is the cache cleaned up? There is a ’last-expiry-cleanup’ that tracks and does the job. Basically, you do not have to worry about this ~/.cache/guix/. All is automatically managed. When the user runs ‘guix gc’ or the sysadmin also ’guix gc’ then this cache is cleaned up if it is too old. Now the question is about what does it mean “too old”? Although “guix time-machine -C channels.scm -- shell -m manifest.scm” will rebuild all if required, it can be at the wrong moment. Therefore, for some very specific environment that I want to protect from “guix gc”, I create a profile for them. Note it is rare and thanks many improvements, it becomes more and more useless. Obviously, if “guix gc” is never run, the manual management of “profile” is fully useless, IMHO. Cheers, simon
Re: Guix-packaged Emacs 29+ alpha-background parameter does not work
Hi, On mar., 02 janv. 2024 at 09:55, B D wrote: > I noticed that the Emacs 29.1 alpha-background frame transparency does not > work using the 'emacs' package in the standard guix channel. Some helpful > people in the #guix irc channel tested it for me on their system and ran > into the same issue, where the frame remains opaque. [...] > This bug looks very reproducible, though I have pasted some information > below about my particular Guix system. Maybe it would be worth to open a bug report for tracking this bug. Cheers, simon
Re: How to use pipewire for jack application?
Hi, Well, I have missed if you get an reply. :-) On ven., 22 déc. 2023 at 04:52, Apoorv via wrote: > On system like Arch Linux, there is a package pipewire-jack which you > can install and then any app that can use jack automatically sees the > jack server running. On Guix there is no such thing. I can do pw-jack > APP from command line to launch the said app such that it can utilize > jack. > > How does one automate this like Arch Linux does for example? I do not use this so I cannot help. Maybe Ricardo? Cheers, simon
Re: Running untrusted code as root in a `guix system vm`?
Hi, On ven., 29 déc. 2023 at 23:40, Ben Weinstein-Raun wrote: > I'm considering running some software inside a VM created using `guix > system vm`. The easiest thing to do would be to run the virtualized > software as root. Normally I wouldn't think twice about that, but iiuc > the guest will have the host's /store mounted. Am I right that this > should make me nervous about running untrusted things as root in the VM? > Or is there some trick by which a root process in the VM is prevented > from destructively changing /store? What do you mean by “destructively changing /store”? Cheers, simon
Re: guix offload
Hi, Sorry for the late reply. On mer., 20 déc. 2023 at 14:02, Aleksandr Vityazev wrote: > Is it possible to make the build continue locally after several > unsuccessful attempts? That’s a feature I also would like. :-) Some pointers for the interested reader: bug#24496: offloading should fall back to local build after n tries ng0 Wed, 21 Sep 2016 09:39:48 + id:8760ppr3q3@we.make.ritual.n0.is https://issues.guix.gnu.org/24496 https://issues.guix.gnu.org/msgid/8760ppr3q3@we.make.ritual.n0.is https://yhetil.org/guix/8760ppr3q3@we.make.ritual.n0.is offload configuration dependant on context zimoun Thu, 16 Dec 2021 14:24:57 +0100 id:86zgp0hec6@gmail.com https://lists.gnu.org/archive/html/help-guix/2021-12 https://yhetil.org/guix/86zgp0hec6@gmail.com Cheers, simon
Re: why does '-e' work differently in guix shell and guix package?
Hi, Well, I have missed if there is a reply. In case not. :-) On mar., 26 déc. 2023 at 11:48, Alexander Asteroth wrote: > When I do > ``` > $ guix shell --network --container --emulate-fhs bash coreutils -e > '(list (@@ (gnu packages commencement) gcc) "lib")' > ``` > I get a shell, that has `libstdc++.so.6` in `/lib`. > > But when I do > ``` > $ guix package -e '(list (@@ (gnu packages commencement) gcc) > "lib")' > guix package: error: expression "(list (@@ (gnu packages > commencement) gcc) \"lib\")" does not evaluate to a package > ``` > I get an error. Why is that? That’s because “guix shell” relies on ’read/eval’ and “guix package” on ’read/eval-package-expression’; both defined in the module (guix ui). As you see, --8<---cut here---start->8--- (define (read/eval-package-expression str) "Read and evaluate STR and return the package it refers to, or exit an error." (match (read/eval str) ((? package? p) p) (x (leave (G_ "expression ~s does not evaluate to a package~%") str --8<---cut here---end--->8--- “guix package” expects that the expression returns a ’package’ when it returns a list. Well, indeed it seems inconsistent and “guix package” could be updated to also just use ’read/eval’. Cheers, simon
Re: How to debug a failed build of rust application under cargo-build-system?
> Tomas Volf <~@wolfsden.cz> hat am 15.02.2024 17:23 CET geschrieben: > > Oh... Right, so I managed to track down the difference. The importer uses > async-stream in 0.3.2 while cargo in 0.3.5. After updating the packaged > version > to 0.3.5, it now compiles, so that is nice. > > Wait, it is not. I assumed that rust is big on the semver. Should 0.3.2 and > 0.3.5 be the same (except bug fixes)? :-O This was in fact a bug fix in 0.3.3: https://github.com/tokio-rs/async-stream/blob/master/async-stream/CHANGELOG.md#033 I have been bitten by Guix's "let's disregard patch versions unless it's version 0.0.x" style a few times now. > But thanks to you I managed to solve this, so thanks :) Happy to hear you solved it!
Re: Python package with some rust dependency
Hi, So right now I'm trying to go the splitting in two packages way, similar to what is done for python-cryptography. So I managed to build the first one that produces a header file in the store /gnu/store/*/lib/header.h In the second package, I don't get how to copy this file inside the build. I've been trying something like this: ``` (native-inputs (list python-fwdpy11-rust-lib)) (arguments (list #:phases #~(modify-phases %standard-phases (add-before 'build 'copy-rust-lib (lambda* (#:key native-inputs #:allow-other-keys) (copy-file (search-input-file native-inputs "lib/fp11rust_api.h") "lib/core/internal/fp11rust_api.h")) ``` Which complains there is no match, because it seams the package store path is not present in the native-inputs, although I specify it in the package. Thanks, Alexis On 13/02/2024 13:55, Alexis Simon wrote: Fair enough, I just meant that it's pretty hard as a newcomer to know which build system You're supposed to use to start with when encountering a project where several languages are used. Alexis On 13/02/2024 13:46, Carlo Zancanaro wrote: On Tue, Feb 13 2024, Alexis Simon wrote: Ok, this seems really counter intuitive though to go and use the cargo build system for a python package only have a tiny part in rust. I'm not sure why this is counter-intuitive. The existence of any rust at all means you need to build rust code. The normal way to do that in Guix is to use the cargo-build-system. Equally, I don't find it strange that the upstream build instructions[1] ask me to install a rust compiler and cbindgen. I need to do that if I want to build rust code. It's also worth noting that there are 22 packages in Cargo.lock[2], so building the one rust file in the repository is a bit more involved. Carlo [1]: https://molpopgen.github.io/fwdpy11/misc/developersguide.html [2]: https://github.com/molpopgen/fwdpy11/blob/main/rust/fp11rust/Cargo.lock
